For the Visual Studio 201x projects, we can force the "install" projects
to always run in a simpler way, by specifying an output file that will
never exist. Makes things look a bit cleaner.
We may not have $(CopyDir) created, which the script that generates the
.pc files check for, so create it if it is not there. This makes things a
bit more convenient for people.
Add a generic script, pc_base.py, which can be utilized to obtain path
info, along with user-input version info, which can be used to generate
pkg-config .pc files. Also enhance replace.py a bit so that it can also
be used in the future to replace multiple items in a file in one shot.
This is done to make building introspection files easier, as it depends
much on the pkg-config .pc files to work.
Update the project files so that when Python is available, we can generate
the full, usable .pc files when we complete and 'install' the builds, and
copy them to appropriate locations so that pkg-config can be set to find
them easily.
... from glib-gen-srcs.[vsprops|props].in to
glib-version-paths.[vsprops|props].in, and instead let autotools generate
glib-version-paths.[vsprops|props] rather than
glib-gen-srcs.[vsprops|props], as this will need to be referenced for
other items as well, namely generating the .pc files which will become
useful for introspection builds.
... for builds using the PCRE bundled with the GLib sources, so that
pcre_version() will also be defined, and be exported so that the regex test program
will properly link when the bundled PCRE sources are used.
This is a follow-up commit to 476f30a.
This is a follow-up commit for commit 82c2461, where the default build is
to use the PCRE that is installed in the system, if it is available and is
not overridden with --with-internal-pcre.
For Visual Studio builds, this means that the new 'Debug' and 'Release'
configs will now use PCRE that is found on the system, which were renamed
from the '*_ExtPCRE' configs; and that there are now 'Debug_BundledPCRE'
and 'Release_BundledPCRE' configs which make use of the PCRE that is
supplied with the GLib sources, which, replaces the former 'Debug' and
'Release' configs.
This partially reverts dc4361f.
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.
The Visual Studio projects used a default setting for link-time code
generation, which is a part of the various linker optimizations that is
available, which is set as /LTCG for Visual Studio 2013 and earlier.
This changed in Visual Studio 2015 to become /LTCG:incremental, which would
cause GResources-generated code to be optimized out during linking, unless
they were referred to directly in the main line code (such as when the
GResource is manually registered), causing programs to crash as a result as
they can't find the needed code/data at run time.
Fix this by explicitly setting /LTCG for all release builds, for Visual
Studio 2010 and later.
https://bugzilla.gnome.org/show_bug.cgi?id=752837
Use /ltcg (link time code generation) for linking as well.
In fact, whole program optimization and /ltcg are the default for Release
builds, so we don't really have to set them explicitly in the projects, so
as a result, we can clean up the projects a little bit.
https://bugzilla.gnome.org/show_bug.cgi?id=752837
List the files that are generated in the process to generate the
glib-install property sheets, so that we can use that list as a
depedency, as well as deleting those files in one shot after the
property sheet is generated, so we don't need to worry about those
in 'make distclean' or so.
Use a simple all-purpose utility script to generate the glib-mkenums
PERL script with the version info, and stop using the script that
tries to parse the autotools files. Move the things that
were taken out from build/win32/setup.py back there.
Make use of the common autotools module that is used to generate the MSVC
project files from their respective templates so that the main build files
beccome cleaner, and enhance them in a way that the headers that should be
installed can be written to the property sheets during 'make dist', so that
the chances of missing headers for MSVC builds can be greatly reduced.
Also use this autotools module to fill in the projects for
glib-compile-schemas and glib-compile-resources.
https://bugzilla.gnome.org/show_bug.cgi?id=735429
Update the .pdb file generation for the MSVC 2010+ DLLs (and the x64 gspawn
helper programs), so that they match the names of the DLLs/EXEs that are
built. Also update the .lib generation so that all will use -$(ApiVersion)
from the property sheets instead of the -2.0 which was previously hard
coded (as we will eventually move into GLib 3.x in the future, for example)
Link to zlib1.lib for all builds, as:
-The notion of zlib1d.lib is rather not standardized across the board for
most cases.
-Easier for the grand all-in-one solution file.
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 project to "install" the GLib files, as we are planning to have
a grand solution file that would build the entire GTK+ stack with its deps,
to ease the process for people building the GTK+ stack from a stock
installation of Visual Studio.
We are including the autocleanup headers as public headers for all builds,
although they work only for GCC in reality, so "install" them.
Also clean up a bit as we are having "\\" in places, where we only need
"\".
This updates the glib-install.[props|vsprops] so that the headers to
"install" for the build are kept up-to-date. Note that this has been
generated by a script, so that this hopefully means that the header
"installation" can be maintained along with the autotools files for most
uses, to simplify maintenance.
As glib-mkenums would likely be used in the building of the other
components of the stack, such as Cogl, Clutter and
gsettings-desktop-schemas, generate that using a Python script (if Python
can be found) and "install" it.
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.
There are many test programs that are shipped with GLib, and this project
is a one-to-one project, which does not make sense to keep as various test
programs may have different CFLAGS, etc, which will require different build
options.
Make the projects include a single property sheet as necessary, which will
in turn include the other property sheet(s) as needed, so that we can avoid
warnings where we include the same property sheets twice in a single
project.
Also make the copying of pre-configured headers into custom build rules so
that they can be removed upon the clean command from the IDE and that they
can be re-copied if their counterpart *.h.win32 are updated.
...where possible, to make application of patches easier in the future.
The README.txt's and the .sln files are still in Windows/DOS line endings
as they need to be so.
Install the Python scripts that is used by gdbus-codegen in
share\glib-2.0\codegen, to be consistent with the other platforms.
Please see https://bugzilla.gnome.org/show_bug.cgi?id=702862 for details
on this.
Due to the split up of the property sheets, the install projects did not
have info on the Intermediate and Output Paths, which caused confusing
messages from Visual Studio to show up upon completing build+"install" and
closing Visual Studio on whether to reload the install project, at least on
Visual Studio 2008.
Include the property sheet which defines these properties to fix this.
Like the Visual Studio 2008 project files, split up the property sheets
so to ease maintenace, and to prepare to use autotools to fill in the
header entries to "install".
Put some of the items that are frequently repeated in the projects as well,
also to simplify maintenance.
Also, update the autotools files to automate the upgrade of Visual Studio
2010 project as we now have multiple property sheets to copy and process.
This is needed for GetAdaptersAddresses()[1], which was used to implement
if_nametoindex on Windows, notably on Windows XP, in commit 01156b12.
if_nametoindex and if_indextoname, as noted in config.h.win32(.in), is
available with Windows Vista and later, so when we eventually drop
support for Windows XP, we can call them directly, and these functions
also reside in the same iphlpapi.lib
[1]: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365915%28v=vs.85%29.aspx
Build and "install" the gio-querymodules and gdbus utility programs so that
the Visual Studio builds of GLib is more comprehensive. The Python scripts
for the GDBus codegen will be added to "installation" later.
Update G_LOG_DOMAIN to be "GLib-GObject" so that we are consistent with
the autotools builds, and that tests expecting the log domain to be
"GLib-GObject" would not fail.
Define the G_LOG_DOMAIN of the GLib DLL as "GLib", because:
-This makes it consistent with the autotools builds
-Some tests expect the log domain to be "GLib"
