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)
Very low use, only two distinct font files, Apple Chancery.ttf and Hoefler Text.ttc
have it so it really doesn't worth the size addition and so, but one may argue that
whole ligature caret is low use but guess we better to encourage GDEF one anyway.
This was done in #770 but no indication of anyone is using it,
let's remove it from our meson port and we can just don't care about
it in autotools port after the migration to meson.
Instead of passing dependencies as required we used one giant shared
dependency list containing all dependencies for every library/executable.
While this kinda works, the specified deps are also used for generating
the pkg-config files and this leads to lots of Requires.private and Libs.private
entries which aren't really needed.
This removes the "deps" array and replaces it with a few smaller ones and
makes sure the public libraries only get passed the dependencies actually
needed.
Fixes#2441
So one can run a category of interested tests like
meson test -Cbuild --suite aots --suite src --print-errorlogs
Intead issuing particular tests which also is possible like
meson test -Cbuild test-shape --print-errorlogs
This way it won't ruin incremental builds.
We need a better way to declare source altering tasks
https://github.com/mesonbuild/meson/issues/7156
yet this is good enough despite being not idiomatic.
It is however not that smooth yet as the change may is detected on the
next meson run. One of course can issue ./gen-ragel-artifacts.py
manually for better experience before running meson.
Using a C linker was limited to non-Windows as 20a840c7, let's
revisit this while transition to meson.
Packagers easily override that via the option and use a C++ linker
if needed.
In case a user passed -Dintrospection=enabled the build would just ignore
it by default because gobject defaults to disabled and the introspection build
gets skipped.
Instead, if introspection is explicitly enabled but gobject is for some reason
missing error out.
Fixes#2404
This adds a seperate library like with autotools.
This also fixes the ico feature option which was just set to required:false
when disabled instead of really disabling it.
Disabling is still broken with msvc because it then tries to find the library
another way, but that's broken for all other deps as well so I left it as is.
For tests only test-unicode.c is using icu specific functions so split it out
into its own category which depends on harfbuzz-icu.
Fixes#2338
Pass the same config to gobject-introspection as with cmake/autotools.
This makes sure the c-include and package name is included in the gir
and also fixes the build because of the missing HB_AAT_H* defines.
Fixes#2336
* Search src/ build directory for objects in check-static-inits.sh
* Find .def files in src/ build directory in src/check-symbols.sh
* Pass builddir also in autotools also, we may just remove libs passing after autotools removal
* Move harfbuzz_subset_def target so can be referenced as a check-static-inits.sh dependency
MSVC doens't like its NullPool,
test-bimap.cc.obj : error LNK2019: unresolved external symbol "unsigned __int64 const * const _hb_NullPool" (?_hb_NullPool@@3QB_KB) referenced in function
test-unicode.c:960: undefined reference to `hb_icu_get_unicode_funcs'
test-unicode.c:961: undefined reference to `hb_icu_get_unicode_funcs'
For now add the icu sources to libharfbuzz also for the amalgam
build, later we need to have a separate harfbuzz-icu module and
link against that, and/or generate harfbuzz.cc.
...and supersede the configuration option uniscribe with gdi, as Uniscribe is
tightly tied to GDI. This means that enabling GDI would also mean enabling
Uniscribe.
We don't actually need the .def files (vs_module_defs) entry when we are
building DLLs with Visual Studio as long as we have HB_DLL_EXPORT defined.
Plus, to maintain compatibility with the CMake builds, for Visual Studio builds
we do not prefix the libraries with 'lib', nor have a '-0' suffix for the DLL
file name.
HarfBuzz headers are under src/ not the root directory, without using
incsrc no headers will be found by the dependent project. I think
incbase is superfluous, it should be replaced by incsrc or dropped.
Qunxin Liu
Khaled Hosny
Behdad Esfahbod
Garret Rieger
josephshen
David Corbett
Myaamori
Fabrice Fontaine
Ross Burton
Khaled Hosny
ebraminio
Tom Schoonjans
Jan Alexander Steffens (heftig)
Nirbheek Chauhan
Christoph Reiter
Hugo Beauzée-Luyssen
Tim-Philipp Müller
Chun-wei Fan
Aaron Boxer