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.
This first adds a common autotools module that can be included by
the Makefile.am's to generate the file lists and the g-ir-scanner/
g-ir-compiler command lines to build the introspection files.
The autotools files for gdk/ and gtk/ are then updated to generate
the full file lists needed to build the introspection files, with
the full command lines for g-ir-scanner and g-ir-compiler as NMake
Makefile modules that can be used to build the introspection files
for Visual Studio builds.
https://bugzilla.gnome.org/show_bug.cgi?id=765195
We are actually not using the crypt() in GDK-Broadway for quite a while,
so the code implementation for MSVC is actually not used. So, it's time
to get rid of this.
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.
"Add" Visual Studio 2015 projects by what we did before: Copy the Visual
Studio 2010 project files and replace the items in there as needed, as
the formats of the 2010 and 2015 projects are largely the same.
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 the /MP compiler option, where the build time for release builds can
be cut down by quite a bit. This will however cause a brief warning with
debug builds due to the use of /Gm, but the code will otherwise build
normally. Unlike the Visual Studio 2010+ builds, we can't use /d2Zi+ as
Visual Studio 2008 does not support that, so we can't get a better
debugging experience for release builds here.
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.
