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.
Since the support for GL support in the GDK Windows backend has landed in
master, we need to build it in the Visual Studio builds. Update the
projects for that and "install" the public header that was added.
As the print preview command is moved into the sources, don't define it in
the preprocessor definitions. However, define the
GTK_PRINT_BACKEND_ENABLE_UNSUPPORTED in the preprocessor definitions, to
make the build in-line with the autotools builds.
The files for build of GtkInspector have been intergrated into the build of
the main GTK+ DLL, and the Visual Studio project templates for those have
been removed as well. Make that removal complete by removing from the
solution files references to it and make the 'gtk' project not to depend on
the gtk-inspector project.
...for Broadway builds, as it was producing a wrongly-named check file for
that configuration, so that a clean would not be correctly performed and
subsequently affected rebuilds.
The gtkglarea and sidebar demos have been added, so build them in the
projects. Note that the gtkglarea code is not usable under Windows at this
point as implementation is needed for the GDK-Win32 backend.
Patches have been submitted to the libepoxy project so that it can be built
under Visual Studio. This will allow the GDK, GTK and gtk3-demo projects
to build, but the gtkglarea code is not usable at this time as
implementation needs to be added to the GDK-Win32 backend for it.
"Install" gdkbroadwaydisplay.h, as it is a public header of GDK Broadway,
also fix the MSVC 2010+ gtk-copy-gdk-broadway.props property sheet as a
'>' is missing. Sorry for not noting these issues earlier, as MSVC
Broadway builds were recently restored. My bad :|
There is now a broadway-buffer.c source that needs to be built for this, so
add it into the projects. Since crypt() is no longer used, don't include
crypt.c in the builds, and so clean up the projects a bit.
Tell people that they need to download and install the Adwaita icon theme,
by following the instructions given on
https://live.gnome.org/GTK%2B/Win32/MSVCCompilationOfGTKStack.
Also tell people they can either use IJG JPEG or libjpeg-turbo for non-GDI+
builds of GDK-Pixbuf.
This updates the property sheets that are used to "install" builds of GTK+
after the libraries and the gtk3-demo programs are built. Note that these
are generated with scripts in regards to the headers part, so that we can
move the header installation part to use autocompletion by the autotools
build files in the next dev cycle or so, like the "gdk" and "gtk" project
files.
Make the Visual C++-related build files contain the actual GTK+ version, by
generating them during the configure stage and dist'ing them in the release
tarballs. This is especially important for builds of introspection files,
as one may need to look at the release version of GTK+ in those files.
Define ISOLATION_AWARE_ENABLED for the build of the GTK DLL so that visual
style can be applied to the Windows print dialog for all applications using
gtkprintoperation.
Update the script for the generation of gtk-win32.rc for MSVC to not try to
embed the manifest from it (but embed libgtk3.manifest by including it in
the project files, as we are now doing), and embedding the manifest file is
really not supported in MSVC 2010 and later.
Also fix up formatting in the GTK DLL projects.
https://bugzilla.gnome.org/show_bug.cgi?id=733773
Use the Python script that was used to create gtk-win32.rc from
gtk-win32.rc.in to similarly create libgtk3.manifest. As the wildcard
character can be used for all architectures, use that.
The libgtk3.manifest file needs to be specified explicitly in the projects,
so that it will be recognized and built into the GTK dll, so update the
project files as well on this part.
https://bugzilla.gnome.org/show_bug.cgi?id=733773
This utility would likely be useful for Windows builds of GTK+, given the
reasons Alex cited for coming up with this utility[1], and MSVC build
support for librsvg is not available at this time (possible, but not
implemented yet).
[1]: https://bugzilla.gnome.org/show_bug.cgi?id=730450
