We implicitly require it for building ragel subproject. This new version
requirement should satisfied in both Fedora 33 and Debian bullseye, and
not be too cutting edge for us.
Add an option to build fallback ragel subproject when no suitable ragel
version is found, and make it off by default since most builder don’t
need ragel at all.
Fixes https://github.com/harfbuzz/harfbuzz/issues/3208 (hopefully)
If ragel 6.10 is not found, build it from source.
Seems to work, except that ragel uses exceptions and we configure
HarfBuzz build to not use exceptions, and I can’t find away to enable
exceptions only for the ragel subproject. I had to remove cpp_eh=none
from default options and try to disable exceptions in MSVC manually
(other compilers are already handled).
Ragel 7 is also not stable from upstream's point of view.
This uses “version” argument find_program(), which was introduced in
meson 0.52.0, so I raised the minimum required meson version
accordingly.
@CURRENT_SOURCE_DIR@ is not listed as a valid string substitution
for custom targets in the Meson reference, and in practice
it does not get substituted when using the vs2019 backend.
introspection can be enabled when cross-compiling on certains conditions
(for example it is supported by buildroot) so, as suggested by
Tim-Philipp Müller, disable it by default for cross builds unless the
option was explicitly enabled by the user
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Currently with Meson hb-version.h is generated during the build without
any explicit dependencies which can result in build failures due races
over the file.
Change this to be generated at configure time, so that the file is always
generated once before the build itself.
Closes#2667
The input file is by definition in the source directory, so dirname()
that instead of needing the directory to be passed.
Needed because a follow-up commit will change when this is called, and the
source directory isn't trivially available at that point.
Only libharfbuzz_gobject is introspectable, not libharfbuzz. Therefore,
it makes no sense to target the latter for introspection: it should
instead be listed as a dependency.
We now have,
$ otool -L src/libharfbuzz.dylib
src/libharfbuzz.dylib:
@rpath/libharfbuzz.0.dylib (compatibility version 0.0.0, current version 0.0.0)
And with the change should we get
$ otool -L src/libharfbuzz.dylib
src/libharfbuzz.dylib:
@rpath/libharfbuzz.0.dylib (compatibility version 20700.0.0, current version 20700.0.0)