[harfbuzz] Various fixups

[ajtribick]

• Add CMake targets harfbuzz::harfbuzz-gpu, harfbuzz-raster, harfbuzz-vector
• Enable OBJC/OBJCXX on Apple targets

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version, or no changes were necessary.
• Any fixed CI baseline and CI feature baseline entries are removed from that file, or no entries needed to be changed.
• All patch files in the port are applied and succeed.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Exactly one version is added in each modified versions file.

[ajtribick]

• probably should also add harfbuzz-icu, harfbuzz-cairo targets if the relevant features are enabled, to match the upstream CMakeLists.txt file
• looks like the /bigobj fix in fix-win32-build.patch is no longer necessary, as it is added in the upstream meson.build
• might as well use auto-generated usage file as there are optional targets

[BillyONeal]

Close and reopen to see if I fixed "check for common mistakes" Sorry for the disruption!

[BillyONeal]

Well the check fails but this time it's actually correct :) ajtribick#1

[ajtribick]

Trying an experiment here: since the Meson build writes all the dependencies to the .pc files, write the CMake targets in terms of pkg_check_modules instead of trying to replicate the logic again in the CMake config file. There is probably a reason not to do that, but let's see...

[dg0yt]

Trying an experiment here: since the Meson build writes all the dependencies to the .pc files, write the CMake targets in terms of pkg_check_modules instead of trying to replicate the logic again in the CMake config file. There is probably a reason not to do that, but let's see...

That's a barrier for Windows users. It is easy to have pkg-config when building the port, but unusual when using it in the top-level project. (I know that it can be wired to host port pkgconf, but...)

What could be explored is transforming pc files to cmake link libs as part of the port. But AFAICT there is no example.

[dg0yt]

I also think every new CMake target should be really prefixed as unofficial. (Too late to change for harfbuzz::harfbuzz.) Unless there is an official variant.

[ajtribick]

That's a barrier for Windows users. It is easy to have pkg-config when building the port, but unusual when using it in the top-level project.

Yeah, I figured it would be something like that. Ah, well.

I also think every new CMake target should be really prefixed as unofficial. (Too late to change for harfbuzz::harfbuzz.) Unless there is an official variant.

Well, these are the targets you'd end up with if vcpkg built with the upstream CMakeLists.txt file instead of the Meson build, so these aren't entirely fictitious targets. On the other hand, the upstream CMake does have the "not actively supported" warning, and vcpkg is synthesizing the targets itself instead of actually building with CMake. I can be persuaded either way here.

[ajtribick]

For now I'm reverting the CMake target updates: as far as I can see, they're no more broken than they were before the 14.2.0 upgrade.

Things that should be fixed in some future update: several optional dependencies (cairo, directwrite, maybe others) never get linked to the harfbuzz::harfbuzz target, the freetype dependency is always linked to harfbuzz::harfbuzz regardless of whether or not harfbuzz was compiled with this, many of the auxiliary library targets are missing.

But hopefully this can fix the reported cross-compile issue in the meantime (i.e. not letting the perfect be the enemy of the slightly better)

[abique]

Thank you everyone, for your efforts 👍

[ajtribick]

Build failure on x64_windows_static_md

[84/154] "D:\downloads\tools\python\python-3.14.2-x64-1\python.exe" "D:\b\harfbuzz\src\14.2.0-73674a17cc.clean\src\gen-gpu-shader-artifacts.py" "src/hb-gpu-fragment-glsl.hh" "D:/b/harfbuzz/src/14.2.0-73674a17cc.clean/src" "../src/14.2.0-73674a17cc.clean/src/hb-gpu-fragment.glsl"
FAILED: [code=1] src/hb-gpu-fragment-glsl.hh 
"D:\downloads\tools\python\python-3.14.2-x64-1\python.exe" "D:\b\harfbuzz\src\14.2.0-73674a17cc.clean\src\gen-gpu-shader-artifacts.py" "src/hb-gpu-fragment-glsl.hh" "D:/b/harfbuzz/src/14.2.0-73674a17cc.clean/src" "../src/14.2.0-73674a17cc.clean/src/hb-gpu-fragment.glsl"
D:/b/harfbuzz/src/14.2.0-73674a17cc.clean/src\hb-gpu-fragment-glsl.hh is out of date; regenerate with a writable source tree

This seems to be a random error copying the file in the gen-gpu-shader-artifacts.py script. Testing locally, it looks like the generated output matches, but I see that the script is operating on the files in text mode but the file comparison in the exception path is binary. What's the line-ending conversion policy used by the vcpkg git wrappers?

[ajtribick]

Raised upstream: harfbuzz/harfbuzz#5967

Might be worth patching the build script to avoid running gen-gpu-shader-artifacts.py - the outputs are already checked in. But will wait for x64_windows to finish building qtwebengine twice just in case some other errors show up.

[abique]

Hey @ajtribick I've tested your changes, and they do not fix #51404

[abique]

Ah sorry I've imported the wrong branch...

[abique]

After compiling the correct branch, I still have the same error.
config-x64-macos-bitwig-rel-out.log
meson-x64-macos-bitwig-rel.log

[BillyONeal]

Thanks!

[ajtribick]

@abique - I based the fix on what was done to fix a similar issue in glib, so my question would be whether glib works in your setup also?

What I have noticed is that the template https://github.com/microsoft/vcpkg/blob/master/ports/vcpkg-tool-meson/meson.template.in uses the spelling OBJCPP in the substitutions, but everywhere else there is OBJCXX. This might be the cause but I don't have any Apple machines to test this with. @BillyONeal are you able to help out here?