hb_shape_plan_key_t::equal expects hb_ot_shape_plan_key_t be initialized by
hb_ot_layout_table_find_feature_variations calls but it won't get initialized
when HB_NO_VAR build config is used.
Related to https://github.com/harfbuzz/harfbuzz/issues/2280
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.
Fixes compiler warning
test-unicode.c:589:1: warning: ‘test_unicode_properties_lenient’ defined but not used
which didn't happen with autotools.
Reason it does with meson is that the setup for C was slightly wrong.
We would only add -DHAVE_CONFIG_H to cpp_args which is only valid when
compiling C++ code, but not plain C code, and many of these tests were
plain C.
Instead pass -DHAVE_CONFIG_H via add_project_arguments() and make sure
to set both c_args and cpp_args when building test executables.
Fixes https://github.com/harfbuzz/harfbuzz/issues/2257
...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.
Since Cairo's build system for Visual Studio does not generate pkg-config files
for us, look for cairo.h and cairo.lib manually if the pkg-config files cannot
be found.
Also look for cairo-ft more carefully: ensure that we have cairo-ft.h, and one
of its symbols can be found in the same cairo.lib that we previously found.
ICU's Visual Studio build files do not generate pkg-config files for us, unless
it is built with Cygwin instead of the project files. If pkg-config files for
ICU cannot be found, look for its headers and .lib manually.
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.
This was, we also avoid Visual Studio compiler warnings C4828 as that sign is
not favored when /utf-8 is enabled, which is the norm nowadays as Visual Studio
2015 or later is required to build harfbuzz nowadays.
Ebrahim Byagowi
Garret Rieger
Simon Cozens
Tim-Philipp Müller
Chun-wei Fan