It was suggested that the project files be moved here as we don't actually
need to go two directory layers from $(srcroot), and would help us to
standardize on things in the future across the board.
Mention that the *.headers are needed only if headers need to be installed
with the project/module after the build. Also, use a generic "YourProject"
rather than the "gdk-4" project file name--I missed changing the name in the
process.
When we make Visual Studio 2013 the baseline Visual Studio version, we need to
the *.vs12.sourcefiles that are generated along the way so that 'make distcheck'
won't complain about the leftover files. This was not caught in GLib as we do
not yet require Visual Studio 2013, but we update this here as this module is
intended to be used in projects that support Visual Studio project builds.
This is to allow specification of the baseline Visual Studio 201x version as
the baseline version may not be 2010 anymore as we begin to require C99
features that will require Visual Studio 2013 or later.
We are starting to require C99 features that can only be supported in
Visual Studio 2013 and later, so we need to prepare rules for Visual Studio
2013 to be our baseline version for Visual Studio builds, so that we can
move the templates from Visual Studio 2010 to Visual Studio 2013.
As this strives to be a shared autotools module between projects, there is
duplication at this point, though, because we still want to support
2008~2012 for projects that do not yet require the C99 features and depends
on GLib-2.50.x/GTK+-3.22.x or earlier.
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.
Allow the use of shorthands using ${prefix} for exec_prefix, and
${exec_prefix} for includedir and libdir, which makes the generated .pc
files a bit cleaner and more flexible.
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.
Some packages might have some parts that are built for certain build
configs, meaning that they could have .pc files of their own, such as
Pango, where PangoFT2 is optionally built. Allow such an option if
needed.
Also remove some trailing whitespaces.
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 adds a NMake Makefile module that can be used for building tests and
introspection using, NMake. This is not yet distributed in the main GLib
tarballs, but this is placed here as the base location as this is
intended to be used in projects that support Visual Studio builds and
support the build of tests and/or introspection under Visual Studio using
NMake.
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
Update the notes that this is also used for Visual Studio 2015 support,
and correct the MSVC_VER_LONG for MSVC 2015, which is 14, not 2015.
Also add a note that this can be used for other projects that have
Visual Studio build support.
Add a note stating that this script can be copied for use to replace
strings in files when necessary, such as replacing autotools variables
in non-autotools builds, such as Visual Studio builds.
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.
This "adds" the Visual Studio 2015 Project files by doing what we did
before: copying the Visual Studio 2010 projects and replacing items
in them, as the formats of the Visual Studio 201x projects are largely
the same.
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.
Update the autotools module so that we can use it to upgrade the
Visual Studio 2010 projects to become Visual Studio 2015-compatible.
Note that this will make the MSVC 2015 builds use the the the latest
VC140 CRT.
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
This adds a common autotools module that can be used by various
projects to generate the Visual Studio projects as needed, and
if necessary, generate the headers listings to "install" for that
project, based on items passed in to this. This is modelled on the
Makefile.introspection autotools file that is used by many GNOME
projects to generate the introspection files.
https://bugzilla.gnome.org/show_bug.cgi?id=735429
The if-else statement added in commit 9bc3ae9 was missing a '\' after the
'else', causing 'make dist/distcheck' to break with "unexpected
end-of-file" errors.
Fix this-didn't notice this when reviewing that patch. My fault. :|
Without this change, out-of-tree distcheck doesn't get very far.
Similarly, allow *.vcxproj, *.props to be in either the builddir or
the srcdir.
Finally, since I'm touching these lines anyway, eliminate some
useless uses of cat: "cat x | sed 's/foo/bar/' > y" is
equivalent to "sed 's/foo/bar/' < x > y".
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=748176
Reviewed-by: Chun-wei Fan <fanchunwei@src.gnome.org>
Make use of pattern rules when generating the Visual Studio 2012/2013
Projects from the Visual Studio 2010 projects, which will help to clean up
the file and also avoid problems when running items like 'make -jN dist'.
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 the /MP option so that each project can build multiple sources in
parallel, which can cut down release build times by quite a bit. This will
cause a brief warning for debug builds due to their use of /Gm, and builds
would otherwise proceed as they did before.
Unfortunately Visual Studio 2008 is too old to support the /d2Zi+ flag, so
we can't make a better debug situation for it at the moment.
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.
