Harfbuzz update to 5.1.0?

LarryB · September 16, 2022, 6:10pm

The latest version of Harfbuzz is 5.1.0.
The current one use by Lime is 1.8.8 ( GitHub - openfl/libharfbuzz ), which is very outdated .

Is it in OpenFL’s future plans to update the Harfbuzz library?
Is this task very difficult?

joshtynjala · September 16, 2022, 6:38pm

Part of this pull request, which I think we’re planning to merge in a bit, is updating Harfbuzz to a newer version:

github.com/openfl/lime

Restructure and update submodules

openfl:develop ← player-03:submodules

opened 10:42PM - 13 May 22 UTC

player-03

+28652 -626

I'm not a fan of how Lime's submodules have been structured up until now. They w…ere created by hand-copying files, and so in order to update them, you have to hand-copy all the new files. However, almost all of the source projects are public Git repos. This pull request takes advantage of that, pointing directly to these repos. Now, updating is simply a matter of checking out a more recent commit, and perhaps updating files.xml. - I added a readme file to introduce people to the project folder, Lime's C++ code, and the submodules. - I switched to libjpeg-turbo, since it has a public Git repo, and is also faster. - We can (and must) now rebuild for Android using more recent NDKs. (Tested with NDK 21 so far.) - liblzma is untouched, as it doesn't have a public Git repo. --- Because it's so much easier to update submodules, I went ahead and updated almost all of them to the latest version. ([Excluding OpenAL](https://github.com/player-03/lime/commit/e027811906f70aec28d1046b0c7adee5addf3bf3) until hxcpp receives an update, and excluding LZMA since there's no official public Git repo.) Of particular note: updating zlib fixes a significant security issue ([CVE-2018-25032](https://github.com/advisories/GHSA-jc36-42cf-vqwj)). --- Because some changes had to be reverted in order to pull this off, I've compiled a list of differences. Hopefully, we can find some other way to resolve these issues, now that directly editing the source files is off the table. Two of the differences are warnings we chose to suppress. They're now back, but is that really a big deal? - [ ] https://github.com/openfl/libpng/commit/601ea3ce9b4af315bed7f371348305b28b3a231c - [ ] https://github.com/openfl/libopenal/commit/e5b5a559075eff71b899094c19d887aec96e1ff3 Then there are some more specific changes: - [ ] [Removing a block of code related to font scaling](https://github.com/openfl/libcairo/commit/70d5bd67f3fc3b904f2ce730f61e7403feb62b05). - [x] [Declaring a variable as `assign` instead of `retain`](https://github.com/openfl/libsdl/commit/370d05558c31570e34c642303705a66a9d0d1547). - [ ] [Including libkern/OSAtomic.h](https://github.com/openfl/libsdl/commit/fa51fcb56b152ba6419b6decfef5dad48b075ac2#diff-e6af188bc44dbb9466a11886afaca34949ef416c76c102f0fae0fba653951223R33-R34). None of these are explained in the commit history. CI builds seem to work fine without them, but I notice that the latter two are related to the `HAVE_GCC_ATOMICS` macro. Maybe the CI build defines it, hiding an error. Or maybe it'll work fine now that we updated SDL.

LarryB · September 16, 2022, 6:53pm

That’s are great news!
All of the stuff in this update looks neat !