There is no point in generating GIR for code interfacing with libraries
without introspection integration. This fixes spurious warnings on macOS
when g-ir-scanner mistakenly tries to scan system headers.
With this change, harfbuzz can be consumed as a subproject without
making any changes to the build files of a project. All you need to do
is provide a wrap file with a `[provide]` section:
https://mesonbuild.com/Wrap-dependency-system-manual.html#provide-section
This is also necessary because otherwise projects need to hard-code
the subproject name, which might be `harfbuzz` when using `wrap-git` or
`harfbuzz-6.0.0` when using `wrap-file` (to build from a release
tarball). This can cause conflicts between different subprojects that
consume harfbuzz differently.
Other projects like glib, cairo, pango, etc already do this.
This reverts commit a335458d57.
While this can be vastly trimmed down, what I did is not right.
It still depends on hb-face, hb-font, hb-blob, hb-set, and hb-map.
This header has defines for all the optional
dependendencies that come with their own Harfbuzz
headers, so you can do:
#include <hb-features.h>
#ifdef HB_HAS_DIRECTWRITE
#include <hb-directwrite.h>
#endif
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.
Behdad Esfahbod
Qunxin Liu
Khaled Hosny
Matthias Clasen
Nirbheek Chauhan
Marco Rebhan
Garret Rieger