... 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.
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)
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.
Split the property sheet into four sheets, to make maintainance of the
build files easier, and also to prepare for using autotools to fill in
the parts for the "installation" of headers.
Also put more of the items that are repeated in the projects into the
property sheets, also to improve ease of maintenance.
Updates to the Visual Studio 2010 projects will come later, as the script
to update them to Visual Studio 2012 must also be taken into account during'
the process.
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"
Since we are now starting to use __declspec (dllexport) to export the
public functions during the build of the GLib DLLs (i.e. to generate the
.lib files), we don't want to generate the .def files from the .symbols
files as we did before for a long time.
This removes from the projects the custom build steps to generate the
various .def files
This will also update the pre-configured config.h(.win32.in) to define
_GLIB_EXTERN appropriately as __declspec (dllexport), as well as making its
entries reflect config.h.in more closely.
Clean/fix up the Preprocessor Definitions for the various projects, where
we purge out the unneeded macros and add _DEBUG to the Debug builds of
various projects that somehow lacked this.
This will also fix the GIO build under Visual C++ 2008, as the _DEBUG macro
in the release builds will cause a debug entry to appear in its manifest
file during the build, which will cause GIO-using applications to fail
to run on systems not running Visual C++/Studio 2008 due to its embedding
of a badly-generated manifest file.
Update the build support of the included PCRE as we are now including
PCRE 8.30 with the GLib distribution.
Also "install" the new gversionmacros.h header file.
-Fix GLib project/filter files generation as some source items are under
the "deprecated" subfolder, and filter out the gthread-*.c
-Explicitly specify gthread-win32.c in the GLib project/filter file
templates, since tarballs are done on Linux.
-Don't define g_static_mutex_get_mutex in the pregenerated
glibconfig.h.win32(.in) as it is defined in deprecated/gthread.h for Windows
Define USE_SYSTEM_PCRE for all configurations which uses the PCRE that
was already built and "installed" beforehand (i.e. the *_ExtPCRE
configurations) so that the compilation will not pick up the
GLib-bundled pcre.h when one wants to use the PCRE "installation" on
his/her system.
-Reinstate build/win32/vs10/glib.sln with the correct EOL (DOS/Windows) so
that the file can be correctly recognized by Windows, rather than having
the "Unrecognized Visual Studio Version".
-Update the main GLib projects to output the DLL/LIB file into <Release or
Debug>\<Win32 or x64>\bin for all configurations.
-Update/simplify the property sheets to copy all DLL and LIB files from
<Release or Debug>\<Win32 or x64>\bin for all configurations.
-Update the VS 2008 property sheet to seperate the intermediate directories
for all projects as well to avoid errors/warnings of being unable to
write/access the PDB files as they are in use.
Added option for people to use an existing PCRE build and updated .def generation for x64 systems (some symbols are set to be excluded from Win64 builds)
Also fixed the filter "PCRE" for the bundled PCRE as file layout changed
Don't keep the lists of source files for libglib, libgobject and
libgio in the VS project files in addition to the canonical location,
the corresponding Makefile.am files.
Instead, generate the corresponding .vcproj files at make dist time
using the C preprocessor, from template files called .vcprojin. We
still list explicitly in the .vcprojin files some of the
Windows-specific source files, and the sources files of gnulib and
pcre.
