Switch to a submodule for harfbuzz. #205
Conversation
|
I guess this is at least good for discussion ... I think this is the right direction to take. We'll have to fix the one CI task though. |
|
It looks like the CI error is: Does the build script need to run autoconf? |
|
In theory, we have to switch to running But that build is used so that we can test linking against harfbuzz on the system and controlling what version it is. An alternative is that we just link against what is on the system and not always provide new API. on macOS, we use what is in homebrew, which tends to be fairly current. on Windows, we don't perform this action and only test using the bundled one in our CI, I think. |
|
My plan was to circle back around to this once we had features re-worked and other things improved ... as that helps make it more clear what exactly we're checking in each scenario. The other harfbuzz bindings always essentially copy our existing logic: Unless a special env var is set, look for one on the system and use it, otherwise, build the bundled copy. But it doesn't bother testing nearly as much in CI. |
waywardmonkeys
force-pushed
the
switch-to-submodule
branch
from
a4b4494
to
c2441b8
Compare
|
@mrobinson This is ready now! This still keeps us on harfbuzz 2.7.4 for now ... just doing the switch of how we get the sources. After that, we can do the actual update to a newer version for our bundled builds. :) |
This simplifies updating as well as reducing the amount of churn in this repo when updating.
waywardmonkeys
force-pushed
the
switch-to-submodule
branch
from
c2441b8
to
3c7872f
Compare
|
@mrobinson Okay, update to the |
|
@jdm Could you land this one too while you are at it, please? |
This simplifies updating as well as reducing the amount of churn in this repo when updating.
This doesn't change the version used or anything yet, it should just be a straight swap from extracted sources to using a submodule.