AuroraMiddleware/harfbuzz
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
3ca9c92aa6
harfbuzz/win32/README.txt

97 lines
5.1 KiB
Plaintext
Raw Normal View History

build: Support Visual Studio builds using NMake This adds a set of NMake Makefiles that can be used to build HarfBuzz, from the standard basic build building the minimal HarfBuzz DLL (consisting of OpenType, fallback and Uniscribe support only), to a full fledged build consisting of GLib and FreeType support, as well as building the utilities, the test programs in src/ and test/api, and HarfBuzz-ICU and HarfBuzz-GObject, and up to building the introspection files. This means a flexible build mechanism is supported here, so anything that is supported for a Windows build (code-wise), should all be supported by this build system. As in an earlier commit, the source listings are shared with the autotools builds with the various Makefile.sources in src/, src/hb-ucdn and util/, and this set of NMake Makefiles will transform these lists into the form they want. In the current form, all the test programs in test/api pass, and this has been checked successfully with 'make -j8 distcheck'.
2015-11-03 11:00:42 +00:00
Instructions for building HarfBuzz on Visual Studio
===================================================
Building the HarfBuzz DLL on Windows is now also supported using Visual Studio
versions 2008 through 2015, in both 32-bit and 64-bit (x64) flavors, via NMake
Makefiles.
The following are instructions for performing such a build, as there is a
number of build configurations supported for the build. Note that for all
build configurations, the OpenType and Simple TrueType layout (fallback)
Make Uniscribe optional on nmake win32 builds Most of harfbuzz clients don't need Uniscribe and DirectWrite support at all as harfbuzz is a replacement for Uniscribe so Chromium and Firefox are using harfbuzz without them on Windows. This removal also helps win32 nmake clients to have reduced binary size and libs count.
2016-10-09 05:36:05 +00:00
backends are enabled, and this is the base configuration that is built if no
options (see below) are specified. A 'clean' target is provided-it is recommended
that one cleans the build and redo the build if any configuration option changed.
An 'install' target is also provided to copy the built items in their appropriate
Win32/NMake builds: Support builds from GIT (#498) Add Python scripts to generate the full win32/config.h.win32 and src/hb-version.h which can be used to build directly from a GIT checkout. Since the scripts are currently intended for building from a GIT checkout, these are not distributed in the release tarballs. Also, support the re-build of Ragel-generated .hh headers using the NMake build system, and allow one to specify the path of the Ragel executable if a suitable one cannot be found in the PATH. Update the Win32/NMake build documentation to let people know about how these mechanisms can be utilized.
2017-06-21 14:19:57 +00:00
locations under $(PREFIX), which is described below. A 'reallyclean' target is
provided that not only does what is done for the 'clean' target, but also removes
the sources/headers that are generated from the Ragel sources. Therefore, if one
is not building from a release tarball, or is rebuilding after using the 'reallyclean'
target or when the Ragel (*.rl) sources are updated, the Ragel state machine
compiler (ragel.exe) is needed, and needs to be passed in via RAGEL=<path_to_ragel_exe>
if ragel.exe is not already in the PATH.
We now support building from a GIT checkout via NMake for convenience. In addition to
the requirements as outlined in the later part of this file, you will need to run the
setup.py (Python 2.7.x or later) script to generate the headers (src\hb-version.h and
win32\config.h.win32) that are normally shipped in a release tarball before running
NMake, and you will need to pass RAGEL=<path_to_ragel_exe> if the Ragel state machine
compiler (ragel.exe) is not in your PATH when invoking NMake. Note that the
'reallyclean' target does not remove these 2 generated headers, so re-run the setup.py
script if necessary.
build: Support Visual Studio builds using NMake This adds a set of NMake Makefiles that can be used to build HarfBuzz, from the standard basic build building the minimal HarfBuzz DLL (consisting of OpenType, fallback and Uniscribe support only), to a full fledged build consisting of GLib and FreeType support, as well as building the utilities, the test programs in src/ and test/api, and HarfBuzz-ICU and HarfBuzz-GObject, and up to building the introspection files. This means a flexible build mechanism is supported here, so anything that is supported for a Windows build (code-wise), should all be supported by this build system. As in an earlier commit, the source listings are shared with the autotools builds with the various Makefile.sources in src/, src/hb-ucdn and util/, and this set of NMake Makefiles will transform these lists into the form they want. In the current form, all the test programs in test/api pass, and this has been checked successfully with 'make -j8 distcheck'.
2015-11-03 11:00:42 +00:00
Invoke the build by issuing the command:
nmake /f Makefile.vc CFG=[release|debug] [PREFIX=...] <option1=1 option2=1 ...>
where:
CFG: Required. Choose from a release or debug build. Note that
all builds generate a .pdb file for each .dll and .exe built--this refers
to the C/C++ runtime that the build uses.
PREFIX: Optional. Base directory of where the third-party headers, libraries
and needed tools can be found, i.e. headers in $(PREFIX)\include,
libraries in $(PREFIX)\lib and tools in $(PREFIX)\bin. If not
specified, $(PREFIX) is set as $(srcroot)\..\vs$(X)\$(platform), where
$(platform) is win32 for 32-bit builds or x64 for 64-bit builds, and
$(X) is the short version of the Visual Studio used, as follows:
2008: 9
2010: 10
2012: 11
2013: 12
2015: 14
Win32/NMake builds: Support builds from GIT (#498) Add Python scripts to generate the full win32/config.h.win32 and src/hb-version.h which can be used to build directly from a GIT checkout. Since the scripts are currently intended for building from a GIT checkout, these are not distributed in the release tarballs. Also, support the re-build of Ragel-generated .hh headers using the NMake build system, and allow one to specify the path of the Ragel executable if a suitable one cannot be found in the PATH. Update the Win32/NMake build documentation to let people know about how these mechanisms can be utilized.
2017-06-21 14:19:57 +00:00
2017: 15
build: Support Visual Studio builds using NMake This adds a set of NMake Makefiles that can be used to build HarfBuzz, from the standard basic build building the minimal HarfBuzz DLL (consisting of OpenType, fallback and Uniscribe support only), to a full fledged build consisting of GLib and FreeType support, as well as building the utilities, the test programs in src/ and test/api, and HarfBuzz-ICU and HarfBuzz-GObject, and up to building the introspection files. This means a flexible build mechanism is supported here, so anything that is supported for a Windows build (code-wise), should all be supported by this build system. As in an earlier commit, the source listings are shared with the autotools builds with the various Makefile.sources in src/, src/hb-ucdn and util/, and this set of NMake Makefiles will transform these lists into the form they want. In the current form, all the test programs in test/api pass, and this has been checked successfully with 'make -j8 distcheck'.
2015-11-03 11:00:42 +00:00
Explanation of options, set by <option>=1:
------------------------------------------
GLIB: Enable GLib support in HarfBuzz, which also uses the GLib unicode
Update Visual Studio builds for UCDN usage We now use UCDN by default, so make it so in the build files; however don't hardcode HAVE_UCDN as one may still opt not to use it (but pass it in as a CFLAG unless one explicitly disables UCDN by using NO_UCDN=1 on the NMake command line). Note that we are not blocking builds where UCDN is disabled along with GLib and ICU, as that will trigger a build error anyways which will tell the user what needs to be done to remedy this.
2017-02-23 05:02:49 +00:00
callback if the bundled UCDN unicode callback is disabled. This requires the
build: Support Visual Studio builds using NMake This adds a set of NMake Makefiles that can be used to build HarfBuzz, from the standard basic build building the minimal HarfBuzz DLL (consisting of OpenType, fallback and Uniscribe support only), to a full fledged build consisting of GLib and FreeType support, as well as building the utilities, the test programs in src/ and test/api, and HarfBuzz-ICU and HarfBuzz-GObject, and up to building the introspection files. This means a flexible build mechanism is supported here, so anything that is supported for a Windows build (code-wise), should all be supported by this build system. As in an earlier commit, the source listings are shared with the autotools builds with the various Makefile.sources in src/, src/hb-ucdn and util/, and this set of NMake Makefiles will transform these lists into the form they want. In the current form, all the test programs in test/api pass, and this has been checked successfully with 'make -j8 distcheck'.
2015-11-03 11:00:42 +00:00
GLib libraries, and is required for building all tool and test programs.
GOBJECT: Enable building the HarfBuzz-GObject DLL, and thus implies GLib
support. This requires the GObject libraries and glib-mkenums script,
along with PERL to generate the enum sources and headers, which is
required for the build.
INTROSPECTION: Enable build of introspection files, for making HarfBuzz
bindings for other programming languages available, such as
Python, available. This requires the GObject-Introspection
libraries and tools, along with the Python interpretor that was
used during the build of GObject-Introspection. Please see
$(srcroot)\README.python for more related details. This implies
the build of the HarfBuzz-GObject DLL, along with GLib support.
FREETYPE: Enable the FreeType font callbacks. Requires the FreeType2 library.
CAIRO: Enable Cairo support. Requires the Cairo library.
CAIRO_FT: Enable the build of the hb-view tool, which makes use of Cairo, and
thus implies FreeType font callback support and Cairo support.
Requires Cairo libraries built with FreeType support. Note that the
hb-view tool requires GLib support as well.
GRAPHITE2: Enable the Graphite2 shaper, requires the SIL Graphite2 library.
Update Visual Studio builds for UCDN usage We now use UCDN by default, so make it so in the build files; however don't hardcode HAVE_UCDN as one may still opt not to use it (but pass it in as a CFLAG unless one explicitly disables UCDN by using NO_UCDN=1 on the NMake command line). Note that we are not blocking builds where UCDN is disabled along with GLib and ICU, as that will trigger a build error anyways which will tell the user what needs to be done to remedy this.
2017-02-23 05:02:49 +00:00
ICU: Enables the build of ICU Unicode functions. Requires the ICU libraries.
build: Support Visual Studio builds using NMake This adds a set of NMake Makefiles that can be used to build HarfBuzz, from the standard basic build building the minimal HarfBuzz DLL (consisting of OpenType, fallback and Uniscribe support only), to a full fledged build consisting of GLib and FreeType support, as well as building the utilities, the test programs in src/ and test/api, and HarfBuzz-ICU and HarfBuzz-GObject, and up to building the introspection files. This means a flexible build mechanism is supported here, so anything that is supported for a Windows build (code-wise), should all be supported by this build system. As in an earlier commit, the source listings are shared with the autotools builds with the various Makefile.sources in src/, src/hb-ucdn and util/, and this set of NMake Makefiles will transform these lists into the form they want. In the current form, all the test programs in test/api pass, and this has been checked successfully with 'make -j8 distcheck'.
2015-11-03 11:00:42 +00:00
Make Uniscribe optional on nmake win32 builds Most of harfbuzz clients don't need Uniscribe and DirectWrite support at all as harfbuzz is a replacement for Uniscribe so Chromium and Firefox are using harfbuzz without them on Windows. This removal also helps win32 nmake clients to have reduced binary size and libs count.
2016-10-09 05:36:05 +00:00
UNISCRIBE: Enable Uniscribe platform shaper support.
DIRECTWRITE: Enable DirectWrite platform shaper support,
MSVC builds: Add support to build DirectWrite shaping backend Add into the NMake Makefiles to build the DirectWrite shaping backend, but as PR #134 mentions, this is considered to be in an experimental state, so don't include this in the build by default for now. This is most probably going to replace the Uniscribe backend eventually, since DirectWrite is meant to be Uniscribe's replacement, and is needed for Windows Store apps if a system shaping API is to be used.
2015-12-09 06:57:15 +00:00
requires a rather recent Windows SDK, and at least Windows Vista/
Server 2008 with SP2 and platform update.
build: Support Visual Studio builds using NMake This adds a set of NMake Makefiles that can be used to build HarfBuzz, from the standard basic build building the minimal HarfBuzz DLL (consisting of OpenType, fallback and Uniscribe support only), to a full fledged build consisting of GLib and FreeType support, as well as building the utilities, the test programs in src/ and test/api, and HarfBuzz-ICU and HarfBuzz-GObject, and up to building the introspection files. This means a flexible build mechanism is supported here, so anything that is supported for a Windows build (code-wise), should all be supported by this build system. As in an earlier commit, the source listings are shared with the autotools builds with the various Makefile.sources in src/, src/hb-ucdn and util/, and this set of NMake Makefiles will transform these lists into the form they want. In the current form, all the test programs in test/api pass, and this has been checked successfully with 'make -j8 distcheck'.
2015-11-03 11:00:42 +00:00
PYTHON: Full path to the Python interpretor to be used, if it is not in %PATH%.
PERL: Full path to the PERL interpretor to be used, if it is not in %PATH%.
Win32/NMake builds: Support builds from GIT (#498) Add Python scripts to generate the full win32/config.h.win32 and src/hb-version.h which can be used to build directly from a GIT checkout. Since the scripts are currently intended for building from a GIT checkout, these are not distributed in the release tarballs. Also, support the re-build of Ragel-generated .hh headers using the NMake build system, and allow one to specify the path of the Ragel executable if a suitable one cannot be found in the PATH. Update the Win32/NMake build documentation to let people know about how these mechanisms can be utilized.
2017-06-21 14:19:57 +00:00
RAGEL: Full path to the Ragel state machine compiler executable, if not in %PATH%
Update Visual Studio builds for UCDN usage We now use UCDN by default, so make it so in the build files; however don't hardcode HAVE_UCDN as one may still opt not to use it (but pass it in as a CFLAG unless one explicitly disables UCDN by using NO_UCDN=1 on the NMake command line). Note that we are not blocking builds where UCDN is disabled along with GLib and ICU, as that will trigger a build error anyways which will tell the user what needs to be done to remedy this.
2017-02-23 05:02:49 +00:00
LIBTOOL_DLL_NAME: Enable libtool-style DLL names.
Reference in New Issue Copy Permalink