In #3811 / commit 53a194aa3f a broken and
half-implemented approach to kind of sort of handling the detection of
both pkg-config and cmake names for dependencies, was implemented. It
just checked for both versions with required: false, but when the build
was configured with *disabled* options, it was still found because it
was treated as auto.
Really, the problem here is trying to outsmart Meson, which handles a
lot of edge cases correctly. But it's possible, albeit very wordy, to
manually implement Meson's internal logic via if/else fallbacks. Do so
here.
Clang 16 has got a new stricter warning for casts of function types
(see 1aad641c79).
This new warning gets included as part of the existing error
diagnostic setting of -Wcast-function-type.
This fixes errors like these:
../src/hb-ft.cc:1011:34: error: cast from 'void (*)(FT_Face)' (aka 'void (*)(FT_FaceRec_ *)') to 'FT_Generic_Finalizer' (aka 'void (*)(void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
ft_face->generic.finalizer = (FT_Generic_Finalizer) hb_ft_face_finalize;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The previous code concatenates includedir to _harfbuzz_prefix verbatim,
which results in a wrong final include path in case includedir is an absolute
path. Instead, we can let meson determine the absolute include and lib paths
in advance and save them in the cmake config.
This is an issue in nixpkgs, where includedir is set to the final (absolute)
path of the built library in the Nix store, which causes CMake projects
depending on harfbuzz to not configure.
See https://github.com/NixOS/nixpkgs/issues/180054.
The rest of layout subsetting depends on lookup indices being consistent with those computed during planning. So if an empty lookup is discarded during the subset phase it will invalidate all subsequent lookup indices. Generally we shouldn't end up with an empty lookup as we pre-prune them during the planning phase, but it can happen in rare cases such as when a subtable is considered degenerate (eg. #3853)