Like what was done in the *.vcxprojin templates, consolidate project configs
that are repetitive, and use the 'Condition=' directive to distinguish between
configuration and/or target platform differences.
...for Visual Studio 2010 and later, since we used to copy them and
merely update the value of $(VSVer) during 'make dist' as needed.
Instead of doing that, move the property sheets for Visual Studio 2010,
which is the base version that we use, into a directory of its own, and
make the Visual Studio 2010~2022 projects look for them in that
directory, and set VSVer according to the toolset version identified by
each of the project files.
The ARM64-specific property sheet needed for VS2017 and the VS2008
property sheets will remain as they are.
We can again use MSBuild trickery to do what was done in the dropped
property sheet.
Unfortunately, like the last commit, I couldn't figure out a way do to
something similar in the VS2008 project files... :|
... and so stop using gtk3-install.[vsprops|props], and remove that
property sheet from the dist and dist the NMake Makefile for the
purpose.
Also remove win32/vs10/gtk3-install.vcxproj.filters as well, as it is
no longer needed.
We will remove the gtk3-install.[vsprops|[props][.in] in a subsequent
commit.
This is an NMake Makefile that will replace the property sheets in the
Visual Studio project files so that we can call it from the project
files to "install" the binaries and introspection files that were built,
along with the header files and other data files, which aims to be
easier to maintain for the current approach.
This will also be expanded upon to optionally build the translation
files and make the installed files more in-line with what are done in
the Meson build files, where there could be compatibility problems with
older Visual Studio toolchains.
Improve the NMake Makefiles that is used to re-generate demos.h(.win32)
by re-generating the gtk3-demo Visual Studio projects, so that one would
no longer need to do that manually.
Update the build instructions accordingly.
Instead of relying on the ones that are currently shipped with the tarballs,
generate them from their .in counterparts prior to the build. This includes
the Resource Scripts (.rc) for libgdk/libgtk, as well as gtkversion.h, in
addition to gdkversionmacros.h which can now be generated during prebuild.
Rename the script as gen-version-items.py, and so make things more generic and
usable by other items in the build. We want to eventually to be able to
generate the .rc files and the *version*.h files from their *.in counterparts
using this script.
This improves the source generating process by:
* Generating the sources in the libgtk build directory, so that we do not
pollute the source tree.
* Support generating gtk[private]typebuiltins.[c|h] in the Visual Studio
projects by using NMake internally.
* Update the projects and the introspection build files so that the generated
sources and headers can be found.
This will enable us to not confuse with the deprecated headers in
gtk/deprecated as those headers are also listed under deprecated_h_sources in
gtk/deprecated/Makefile.inc, when we include the makefile snippets in both
gdk/ and gtk/.
This makes the rest of the sources that are generated being put in GDK's build
directory for the Visual Studio projects, instead of being placed in GDK's
source subdir, so that:
* We can avoid polluting GDK's source tree.
* The Visual Studio builds won't interfere with the Meson builds.
Update the project files to look for the generated sources and headers in the
right places, as well as making the introspection builds look for the generated
sources as well.
Also remove the gtk3-gen-srcs property sheets and put the relevant parts in the
corresponding gtk3-build-defines property sheets, to clean things up a bit.
This way, we can have the introspection NMake Makefiles share more items
with the source generating bits.
Update the Visual Studio projects accordingly
This will make introspection builds via the Visual Studio 2022 projects work as
the NMake Makefiles were looking for VS2019 builds, which most probably did not
exist
Rename README_EGL_MSVC.txt to README_FEATURES_MSVC.txt, as we now have
more features that can be included in the builds using the Visual
Studio projects, which require additional depedencies and manual
enabling.
Specifically, this outlines how the font tweaking feature in libgtk can
be enabled and for people who wish to do so, how to enable the Font
Features demo in gtk3-demo.exe.
We can regenerate demos.h.win32 with or without the font features demo
by using the regenerate-demos-h-win32 target with or without secifying
the FONT_FEATURES_DEMO=1 flag on the NMake command line.
...in the libgtk3 project, so that we can automatically link to
harfbuzz.lib if we have a sufficiently-new version of Pango and HarfBuzz
installed, so that the code to enable font features can be linked
properly, even if we don't explicitly put harfbuzz.lib in the list of
libraries that we feed into the linker in the project files.
If one is using pre-Pango-1.44.x and/or pre-HarfBuzz-2.2.0 and intends
to enable font features support, one still must update config.h.win32 to
make sure HAVE_PANGOFT2 and HAVE_HARFBUZZ is defined, and put
pangoft2-1.0.lib, harfbuzz.lib and freetype.lib (or so) in the
"Additional Libraries" under the linker settings in the projects
manually, as required before.
Like the Visual Studio 2012+ projects, copy the Visual Studio 2010
projects and replace the items in there as needed, so that we can
obtain Visual Studio 2022 project files, since they are all in the
MSBuild format.
Differently from the meson case, here we just include the emoji data
files into the global gresources file, get_emoji_data() supports this
and it's just easier to handle in these build systems.
This will make GTK_HOST defined more like what it is on Meson builds, so that
we set the host string appropriately according to the build that is being
carried out, instead of defaulting to i686-pc-vsXX for all builds.
Like the previous commit on win32/config-msvc.mak.in, this now sets GTK_HOST
to be:
i686-pc-vsXX for 32-bit x86 builds
x86_64-pc-vsXX for x64 builds
aarch64-pc-vsXX for ARM64 builds (requires VS2017 15.9.x or later)
Currently, introspection is not well-supported for ARM64 Windows builds as:
* There is no official Python release for ARM64 Windows, but it is currently
possible to build it with sufficient support for G-I, however...
* The tooling in Python still needs to be updated to enable ARM64 Windows
builds for use with g-ir-scanner and friends, and...
* Introspection builds must be done on an ARM64 system, since we are running a
dumper binary to generate the .gir files
This will attempt to prepare things for building GTK's introspection files on
Windows ARM64, but will require a custom installation of Python as noted above,
for the time being
Instead, rely on the mechanism that we already have to set the platform string
appropriately, eg:
i686-pc-vsXX for 32-bit x86 builds
x86_64-pc-vsXX for x64 builds
aarch64-pc-vsXX for arm64 builds
It turns out that we must put Directory.Build.props in win32/vs10 and let
automake copy it over to win32/vs15/... so do that, and only dist the copy
in win32/vs15.
Update the NMake Makefiles used for generating the various sources be able to
cope with an ARM64 build environment, and update the project files, in
particular for Visual Studio 2017 (VisualStudioVersion 15.0) so that we can
pull in the system .lib's that were somehow excluded from the default list
on ARM64 builds.
Also, add a custom Directory.Build.props in win32/vs15 so that we do not
try to build with the Windows 8.1 SDK by defualt, which is not ready for ARM64
builds, but instead uses the appropriate Windows 10 SDK that supports this.
Update the README.win32 file to give people instructions on how ARM64 builds
can be carried out.
Look in the include/harfbuzz directory that is under the pre-defined prefix
directory, as Pango 1.44.x and later pulled in HarfBuzz headers for all builds
This way, we can enable the built binaries to print out diagnostic
messages as needed by the values we set via the envvar GDK_DEBUG.
The release configs of the Visual Studio project files follow the
settings of Meson's `debugoptimized` build settings.
Update the NMake Makefiles to invoke glib-compile-resources with
'start /min' so that when gdk-pixbuf-pixdata, json-glib-format
and xmllint are invoked by glib-compile-resources, cmd.exe windows
will not popup whenever these auxiliary tools are invoked, when one
builds GTK with the Visual Studio projects.
This will reduce the distraction that is caused during the time the
source files are generated, as a popup cmd.exe window will disrupt the
window focus as they appear, and will make the process a bit quicker.
