Combine repetitive parts, and unify using $(PythonDir) for all builds,
which the paths set in the property sheets are now based on the Visual
Studio version and platform combination.
Not that it will make a difference, but to be consistent with the
autotools builds. Include gtkx.h instead of gtk.h when we generate the
source to feed to the preprocessor.
We now need to generate gtktypefuncs.c by ourselves, so modify the
gentypefuncs.py script from master, and add a custom build step in the
projects to generate gtktypefuncs.c. The custom build step for the 2008
projects will be added later.
Ensure that the /DYNAMICBASE linker option (which is actually the
default) is enabled for all of our Visual Studio project builds, as the
gtk3-demo projects inadvertly disabled it.
Also, for x64 builds on MSVC 2012 or later, enable /HIGHENTROPYVA to
enhance the security of our binaries as well.
Pointed out by Ignacio Casal Quinteiro.
This is so that it is easier for one building GTK+ with Visual Studio to
build the introspection files as well in one shot. Note that this is
not built by default, so one needs to select the gtk3-introspect
explicitly to build (and clean up) the introspection files.
For this to work, one needs to ensure the following:
-A complete build of GObject-Introspection in $(GlibEtcInstallRoot),
that is built with the same installation of the Python interpretor that
is used here (see PythonDir and PythonDirX64 in
gtk3-version-paths.[vsprops|props]).
-Introspection files for ATK, GDK-Pixbuf and Pango, also in their proper
locations under $(GlibEtcInstallRoot), which should be built with the
same G-I installation.
This is to make this more in-line with what is in the G-I projects, so
that we could use this to build the introspection files for GTK+-3.22.x
directly from the project files. This is intended to follow the MSVC
versions used to build the official CPython Windows binaries, i.e.:
-3.3.x, 3.4.x: for MSVC 2010, 2012, 2013, which is built with 2010
-3.5.x, 3.6.x: for 2015 and 2017, which is built with 2015.
Update the autotools scripts so that we can support Visual Studio 2017
by copying the 2010 projects and updating items as needed to obtain
the 2017 projects.
Note that since the toolset version string changed for Visual Studio
2017, so allow the use of a custom toolset version string, otherwise
just generate the toolset version string as we did before.
Also, note that Visual Studio 2017 aims to be compatible with 2015
on the CRT level, so there should not be any problems using 2017-compiled
binaries with 2015-compiled ones.
After building GDK with broadway, we need to copy the GDK DLL from
[Release|Debug]_Broadway\bin to [Release|Debug]\bin, so that the
introspection builds can be done normally with CFG=[Release|Debug]. As we
renamed the projects, we needed to update the property sheets that does
the copying, which was accidently missed. Fix that.
We want to look for the gdk-pixbuf-2.0 package, and we should leave a space
between -ldwmapi and -lzlib1 when we enable Broadway.
Also copy the generated gdk-3.0.pc and gtk+-3.0.pc as gdk-win32-3.0.pc and
gtk+-win32-3.0.pc respectively, to be in-line with the autotools builds.
Split out the part where we generate/update the caches for the GSchemas
and the icons, so that it is easier to ensure that things continue to
function correctly when we have GlibEtcInstallRoot != CopyDir.
Consolidate the .lib's that we need to link to for GDK and GTK+ into the
property sheets, and also link to setupapi.lib as that is needed by
the port to the new GdkMonitor API.
Generate .pc files for the package, so that it would be easier for
building introspection for packages that depend on GTK+. Also split
PythonPath into PythonPath and PythonPathX64 to facilitate the build of
introspection files, which need to have Python that is built with the
same ac=rchitecture where GTK+ is built.
Clean up the formatting and spacing a bit.
Search also for the headers in include/gio-win32-2.0, as gio.h will
include those headers at some point, and arrange the include paths in a
dependency hierarchy style, top-to-down.
On Visual Studio, unlike MinGW, manifest files are embedded via
including the manifest file as a resource file in the projects, not
via the .rc file. This means that the line in the .rc file that
specifies the manifest file would cause trouble, so that line gets
removed when the full gtk3-win32.rc is generated on Visual Studio builds,
otherwise 2010+ Visual Studio will complain when compiling the .rc file.
Also, the inclusion of winuser.h will cause warnings during the
compilation of the .rc file.
Fix this by isolating the Win32 resource portions of gtk-win32.rc.in to
gtk-win32.rc.body.in and:
-On MinGW, construct the full gtk-win32.rc by doing the winver.h and
winuser.h inclusion first, then append the contents of gtk-win32.rc.body,
and then appending the line to embed the manifest file.
-On Visual Studio, simply copy the gtk-win32.rc.body to gtk-win32.rc,
and generate the full libgtk3.manifest file.
https://bugzilla.gnome.org/show_bug.cgi?id=762311
Build the gtk-update-icon-cache, gtk-builder-tool and gtk-query-settings
tools and run gtk-update-icon-cache as part of the post-build
"installation" process.
Pointed out (and reminded) by Paolo Borelli in bug 759436 that we should
build, "install" and run gtk-update-icon-cache in the MSVC builds as well.
glib-compile-resources have been updated to ensure that the symbols
generated are referred to, so that they will not be optimized out by the
linker in release builds. We can change from /opt:noref to /opt:ref,
which should improve optimization a bit.
This partially reverts de16a4e.
As we now ensure that items using GResources and GConstructors are always
referenced so that the linker does not optimize them out in a default
Release build, we no longer need to enforce the use of /LTCG, so
/LTCG:incremental will work as well.
MSVC 2015 changed its default link-time code generation setting to
/LTCG:incremental, which causes problems if /opt:noref is to be used,
meaning that some code will be optimized out by the linker.
Avoid this situtation here by enforcing the use of /LTCG for MSVC 2010+
builds.
Use $(GlibEtcInstallRoot) when invoking glib-compile-schemas, as CopyDir
is not GlibInstallRoot for GTK+ (due to quoting issues), meaning that the
glib-compile-schemas tool may not be found in certain cases.
Issue pointed out by Ignacio Casal Quinteiro.
The recent changes to build/win32/vs9|10/Makefile.am fixed 'make distclean'
but broke 'make -jN dist', so fix that by listing the *.headers and using
that list as a dependency and to remove those files in one single command
right after we generate the gtk-install.vsprops template, so that we don't
have to worry about them in 'make distclean'.
This updates the Visual Studio Project GUIDs so that they don't repeat with
the GTK+-2.24.x ones, as the 3.x projects can be used with the 2.24.x in a
all-in-one solution file (such as when one wants to use a complete GTK+2
and GTK+3 stack when porting Windows applications from GTK+2 to GTK+3), and
each project in a solution file is expected to have an unique GUID.
We need to rename the projects so that when these projects are added
into an all-in-one solution file that will build the GTK+ 2/3 stack,
the names of the projects will not collide with the GTK+-2.x ones,
especially as GTK+-2.x and GTK+-3.x are done to co-exist on the same
system. This is due to the case that the MSVC projects are directly
carried over from the GTK+-2.x ones and was then updated for 3.x.
We still need to update the GUIDs of the projects, so that they won't
conflict with the GTK+-2.x ones.
Use the common automake module from the previous commit in the
Makefile.am's, which means that the Makefile.am's in gdk/ and gtk/ can be
cleaned up as a result. As a side effect, the property sheet that is used
to "install" the build results and headers can now be generated in terms of
the listing of headers to copy during 'make dist', where we can acquire
most of the list of headers to "install", so that we can largely avoid the
situation where the property sheet files are not updated in time for this,
causing missing headers when this build of GTK+ is being used.
Also use the Visual Studio Project file generation for the following
projects:
gtk3-demo
gtk3-demo-application
gtk3-icon-browser
gdk-win32
gdk-broadway
gail-util
So that the maintenace of these project files can be simplified as well.
https://bugzilla.gnome.org/show_bug.cgi?id=681965
Since demos.h is now generated according to the platform for which GTK+ is
built, don't distribute it. Generate a Windows-specific demos.h.win32 and
distribute that instead, in which the Visual Studio build files will copy
it to demos.h, so that the build will proceed normally.
https://bugzilla.gnome.org/show_bug.cgi?id=749622
The current GdkScreen->is_composited() is a stub as we were having Windows
XP being supported, which does not support Desktop Window Manager (DWM),
which is used by Windows for composition.
Windows Vista and later support DWM, and it is always enabled on Windows 8/
Server 2012 and later.
Please note that as we are dropping XP support in this cycle, this is the
commit that would say goodbye to Windows XP support for GTK+-3.x, by
linking directly to dwmapi.dll. This means, we only check whether we are
on Windows 8 or Server 2012 (or later) to see whether we unconditionally
have composition enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=741849
"Install" the .pdb files that were generated along with the build, to make
it easier for people to develop and debug GTK+, especially when used as a
stack, and as the .pdb files are already generated with all builds.
Also make the copy of the .dll, .lib and .exe files more selective so that
we do not accidently copy files that are not meant to be "installed", or
end up making extra copies of plugin DLLs in the wrong places, when the
projects here are included as a part of a grand solution that is used to
build the entire GTK+ stack, for example.
For Visual Studio 2010 and later, the .pdb filename needs to be explicitly
specified so that it will match the filename of the target, if the project
name differs from the filename of the target. Make sure that is the case
for the 3 DLLs that we build for Visual Studio 2010 and later.
Use Multiprocessor compilation which can cut down build times by quite a
bit and use the /d2Zi+ flag to have better debugging info being logged to
the .pdb for release builds.
These are only applicable for Visual Studio 2010/2012 and later.
Rename the "install" projects as "gtk-install" as we are planning to have a
grand solution file that incorporates all project files of the GTK+ stack
with their dependencies, to make it easier for people to build GTK+ from
scratch from a stock installation of Visual Studio 2008 and later.
