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
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.
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.
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.
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.
Added projects to compile the glib-compile-resources and gresource(-tool)
utility programs during the Visual C++ 2010 build process, "install"
the resulting binaries upon successful compilation, and dist the new
.vcxproj and .vcxproj.filters files.
Also updated the property sheet and "install" project to make sure the new
.exe's are indeed "installed" and removed from the "install" project the
dependency on the testglib project as testglib is not an exhausive test on
GLib and people might want to make that project compile different test
programs as they might need.
Just wondering: I have updated the property sheet to create the
gconstructor_as_data.h header for glib-compile-resources, but is it better
to dist that generated header instead as the VS 2008/2010 projects will
depend on a working installation of PERL on Windows?
-Added projects to compile the glib-compile-schemas and gsettings utilities
-Update .vsprops to install these in "install" phase
-Distribute these projects also
These are the actual GLib VS2010 project files (*.vcxproj,
*.vcxproj.filters) and property sheet file (*.props) that are used
to compile the GLib, GModule, GObject, GThread, GIO DLLs, along with
the gspawn-win32-helper* programs, glib-genmarshal utility and
testglib test program. A readme.txt file is also enclosed for
references for building GLib under VS2010.
Note that the project files for GLib, GIO and GObject are templates
that makes use of the autotools items of my last commit so that maintenance
of those files are simplified as new source files are added to these rather
frequently.
Suggestions are welcome for these-please let me know via BugZilla.
Thank you!
