It turns out that we do not need to have separate command lines for
running the Visual Studio preprocessor for 32-bit builds and 64-bit
builds as `_WIN64` is automatically defined by the 64-bit compilers.
This means that we can clean up the project files a bit.
Copy and update the relevant fields from the Visual Studio 2010 projects
so that we can have project files that work out-of-the-box for Visual
Studio 2019, as we did for Visual Studio 2012 through 2017.
Also update the NMake Makefiles for building the introspection files
so that we properly detect that we are building with Visual Studio 2019.
This updates the introspection build process that we also check on
changes in the Makefiles when we generate the NMake Makefile snippets
and file lists, so that any changes to the source file list can be
reflected. Also ensure that we build against the freshly-built
libraries.
Make the NMake Makefiles also output the built introspection items to
the output directories of the various Visual Studio versions, according
to the build configuration and architecture, so that we avoid confusion
for different Visual Studio build configs.
We are not passing in the correct architecture to the script that we use
to generate the pkg-config files for Release/x86 builds and Debug/x64
builds. Fix this.
Just link to Cairo instead of looking for the Cairo .pc file as the
Cairo build system for Visual Studio currently does not generate a
pkg-config file for us. This will eliminate the need to hand-craft a
pkg-config file for Cairo to be able to use the pkg-config files that we
generate here.
Ensure that the /DYNAMICBASE linker option (which is actually the
default option) is enabled, as we inadvertly disabled it in our
projects.
Also, for x64 builds on MSVC 2012 or later, use the /HIGHENTROPYVA
linker option to improve the security of the built bianries.
Pointed out by Ignacio Casal Quinteiro.
Some files that this script will process might have UTF-8 items in
there, which can cause problems on Python 3.x as it is more strict and
careful on unicode issues.
Fix this by:
-Doing what we did before on Python 2.x
-Opening the file with encoding='utf-8' on Python 3.x
Update the autotools scripts so that we can copy the Visual Studio
2010 and update items as necessary to obtain the Visual Studio 2017
projects.
Note that the toolset version string format has changed for Visual
Studio 2017, so a custom toolset version string is allowed and used
if specified, otherwise the toolset version string is generated as
we did before.
Note also that Visual Studio 2017 aims to be compatible with Visual
Studio 2015 on the CRT level, so it should be possible to use 2017-
compiled binaries with 2015-compiled binaries without problems.
Most people should be on GTK+-3.x by now, but in case they don't and are
using GTK+-2.24.x, we ought to "install" the gtk-update-icon-cache tool,
like we did for the 2008 builds, as it is still much used, and is already
built by the projects.
Generate the .pc files when a Python installation can be found at the
location specified by PythonPath (32-bit) or PythonPathX64 (64-bit), which
is found in gtk-version-paths.[vsprops|props].
Make the Makefile.am targets for generating the Visual Studio projects re-generate the
project files and the header listings whenever the Makefile.am's that include
build/Makefile.msvcproj changes, so that whenever a source/header is added, they will
be reflected in the projects and in the property sheets that are used to copy the
headers.
Also ensure that these are applied to the vs11, vs12 and vs14 projects when this
happens, as they are copied and processed from the Visual Studio 2010 projects.
This adds a set of NMake Makefiles to enable introspection building
under Visual Studio builds. As the status of introspection of GTK+-2.24.x
is considered experimental, this support is also considered experimental.
https://bugzilla.gnome.org/show_bug.cgi?id=765193
As pointed out by Paolo Borelli in bug 759436, we ought to build
gtk-update-icon-cache, "install" it and run it nowadays as it becomes more
and more common that we are going to use an external icon theme package,
so that gtk+ programs will run better and faster.
This adds support for building with Visual Studio 2015 out-of-the-box
by what we did before: copying the 2010 projects and updating items
in there to make those projects compatible with 2015, as the formats
of the project files are largely unchanged.
Use the common autotools module that was added in the last commit so that
we can clean up the various Makefile.am's in gdk/ and gtk/, and also
make more Visual Studio projects completed during 'make dist', by adding
minimal items to those other Makefile.am's. This also allows us to make
the property sheets that does the copying of headers and built items
completed at 'make dist', so that we won't have to worry too much about
headers being added (although it would be unlikely for GTK+-2.x).
This updates the autotools module copying and generating the MSVC
2012-2015 projects by copying it from from GLib, which also has the
advantage of making things work better when doing 'make -jN dist', and
the Makefile.am's in bui;d/win32/vs[11|12] have been updated accordingly.
This adds an autotools module that is copied from GLib, which is
included by the Makefile.am's to generate the complete Visual Studio
projects from their repsective templates, which:
-Cleans up those autotools files
-Make 'make -jN dist' work better
The GUID of the "Install" project files happen to be the same as Pango's
"install" projects, so we need to update the GUID here so that the projects
can cooperate with each other when used in an all-in-one build for the GTK+
stack.
Rename the install projects as gtk-install, to ease the integration of the
projects in a grand solution that may be used to build, for example, the
entire GTK+ stack.
"Install" the .pdb files to help people use them to debug the GTK+ stack,
or for their GTK-using applications, as they are already generated for all
builds.
Also update the copying of the DLLs, LIBs and EXEs so that we ensure that
we only copy the items from GTK+-2.x, without accidently copying items that
are not meant to be copied, or make extra copies of items in the wrong
places, such as when the projects here are used in parts of grand solutions
used to build the entire GTK+ stack.
The .pdb file name must be specified for Visual Studio 2010+ later in order
fo match the output filename if the output filename is different from the
project name. Update the projects as necessary.
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.
As the Visual Studio 2012/2013 are only slightly different from the Visual
Studio 2010 projects, we can provide support for them by using scripts to
copy the Visual Studio 2010 projects, and update the specific parts as
necessary. This is being provided to help people still needing GTK+-2.x
and also to help them to transition to GTK+-3.x easier.
Thus, there would be little maintenance overhead for these as only the 2010
projects need to be kept up-to-date as a result. This might change when we
do get the stack working with WinRT/Metro, but that's going to be another
totally different issue.
We need to enclose paths containing $(BinDir) with double quotes as it
points to something like c:\foo\gtk+-x.yy.zz, which the copy command on
Windows does not like "+" in paths unless enclosed in quotes.
Currently, due to the way that Visual Studio 2010+ projects are handled,
the "install" project does not re-build upon changes to the sources, as it
does not believe that its dependencies have changed, although the changed
sources are automatically recompiled. This means that if a part or more
of the solution does not build, or if the sources need some other fixes
or enhancements, the up-to-date build is not copied automatically, which
can be misleading.
Improve on the situation by forcing the "install" project to trigger its
rebuild, so that the updated binaries can be copied. This does trigger an
MSBuild warning, but having that warning is way better than not having an
up-to-date build, especially during testing and development.
As we are likely to have GTK+-2.x around for some time, revamp the Visual
Studio 2010 projects like what was done for rest of the GTK+ stack, namely:
-Split the property sheets, in a way like what was done for the rest of the
stack. Also clean up the resulting property sheets a bit, and update the
projects to use these property sheets.
-Use UNIX line endings for all projects and property sheets, to ease future
application of patches.
-Make the copying of config.h.win32 and gdkconfig.h.win32 into custom build
rules, so that they may be removed properly and re-copied during change
and update.
-Add a PlatformToolset tag, so if we want to support building with Visual
Studio 2012/2013, the transition can be done quite easily with a script,
such as what is now being done for the Visual Studio 2012 projects for
GLib.
As we are likely to have GTK+-2.x around for some time, revamp the Visual
Studio 2008 projects like what was done for rest of the GTK+ stack, namely:
-Split the property sheets, in a way like what was done for the rest of the
stack. Also clean up the resulting property sheets a bit, and update the
projects to use these property sheets.
-Use UNIX line endings for all projects and property sheets, to ease future
application of patches.
-Make the copying of config.h.win32 and gdkconfig.h.win32 into custom build
rules, so that they may be removed properly and re-copied during change
and update.
Similar updates will be applied for the Visual Studio 2010 projects ASAP.
The GDK-Pixbuf Visual Studio 2008 project files have long been moved and
maintain in the gdk-pixbuf project, soon after that was made independent
from the GTK+ project, so these files should no longer exist in the GTK+
git repo, especially as they are no longer distributed for a long time.
...so that we will include the correct gdkconfig.h, which would be
in $(srcroot)\gdk\ during the Visual C++ build.
Also prepare support for Visual Studio 2012 in this project, so it would
be easy to use a script to copy and replace the necessary items in the
Visual Studio 2010 project set to make it a Visual Studio 2012 set.
The Visual C++ project files for GTK+-2.24.x need to be updated as the
Windows theme engine (libwimp) currently has to be built as a DLL.
This adds the Visual C++ 2010 project file to build libwimp as a
standalone module/DLL, and the property sheets, .sln file and
gtk.vcxprojin/gtk.vcxproj.filtersin/install.vcxproj are updated
accordingly so that the needed stuff get built properly and go
to the proper places for the Windows Themes to work correctly
with the Visual C++ builds.
Thanks to nus for pointing this out.
The Visual C++ project files for GTK+-2.24.x need to be updated as the
Windows theme engine (libwimp) currently has to be built as a DLL.
This adds the Visual C++ 2008 project file to build libwimp as a standalone
module/DLL, and the property sheets, .sln file and gtk.vcprojin are updated
accordingly so that the needed stuff get built properly and go to the
proper places for the Windows Themes to work correctly with the Visual C++
builds.
Thanks to nus for pointing this out. Visual C++ 2010 projects files will
be updated in the next 1-2 days.
