Instead of passing a CFLAG/CXXFLAG to define HB_EXTERN, define it
directly in src/hb.hh as __declspec(dllexport) extern when we are
building HarfBuzz as DLLs on Visual Studio. Define HB_INTERNAL
as nothing without defining HB_NO_VISIBILITY when building HarfBuzz as
DLLs to avoid linker errors on Visual Studio builds.
Also "install" harfbuzz-subset.dll into $(PREFIX)\bin as the
hb-subset utility will depend on that DLL at runtime, when HarfBuzz is
built as DLLs. Since it consists of private APIs that are subject to
change, we do not install its headers nor .lib file.
When building with the auto tools, the manually mantained
harfbuzz-config.cmake is installed. When building with cmake, we can use
cmake to generate the correct config files for us and install them.
The list of source files to pass to g-ir-scanner is becoming too
long for Windows, as Windows imposes a 8192-character limit for command
lines, so we need to first transform that list into a listings file, and
then use the --filelist option for g-ir-scanner to build the
introspection files.
Not all the compilers that HarfBuzz is buildable on supports round() and
has the header stdbool.h, so we check for them and define HAVE_ROUND and
HAVE_STDBOOL_H repsectively in our CFLAGS so that we include them only
when they are found, or use fallback implementations when necessary.
Also include FindPythonInterp earlier as we need PYTHON_EXECUTABLE to be
set for running the tests.
Also, call c++filt on their results.
Also build and fix and check harfbuzz-gobject.def
Also changes harfbuzz-gobject to distribute generated enum sources.
This adds support for introspection builds on Windows that is enabled by
the HB_HAVE_INTROSPECTION option, which will also enable HB_HAVE_GOBJECT
(and so HB_HAVE_GLIB) as they are required for introspection.
In order for this to work one must ensure that the Python installation
listed in PYTHON_EXECUTABLE is the same Python release series that was
used to build _giscanner.pyd (the Python module that is used by
g-ir-scanner), with the same architecture. PKG_CONFIG_PATH and PATH
must be set correctly if $(PREFIX)\bin and/or $(PREFIX)\lib\pkgconfig
are not in the standard PATH and PKG_CONFIG_PATH, which is actually
in-line with the *NIX builds.
This adds support to the CMake build files to support building
HarfBuzz-GObject, which is actually a little bit complicated,
as we need to:
-Run glib-mkenums, which is a Python (for newer GLib/GObject) or PERL
(for older, pre 2.53.4, GLib/GObject) script. This matters more for
Visual Studio builds as shebang lines are not supported, so we need to
test-run it with PERL or Python to determine which is the correct
interpretor to use.
-Next, we need to replace strings in the sources that we obtain from
running glib-mkenums. So, the solution here is to use a small utility
CMake script for our purposes here, to maintain maximum compatibility.
-Ensure that things do work in the Visual Studio IDE builds.
Include the fallback sources in the build, and update
src/Makefile.sources so that it can be read by the CMake build files.
Fix a typo in the DirectWrite configure option so that we can properly
enable DirectWrite builds.
Also, when building the utility program, install them as well.
Instead of searching for freetype using pkg-config, use the FindFreetype
feature of CMake. This allows for better integration with other projects
that make use of CMake.
Fixes https://github.com/behdad/harfbuzz/issues/518
Chun-wei Fan
Simon Hausmann
Cosimo Lupo
Ebrahim Byagowi
Nikolaus Waxweiler
Joel Winarske
Nikolaus Waxweiler
Garret Rieger
Behdad Esfahbod
rdb
Bruce Mitchener
Khaled Hosny