-Make up for the missed DLL_EXPORT-it's actually needed for all GLib DLL
builds, omitting this caused problems to surface due to recent works to
make GDBus work on Windows.
-Also use the FFI_BULIDING macro for GObject builds as the suggessted
workaround for using static LibFFI builds (as we do now)-please see
ffi.h(.in). This will fix the build of GObject against LibFFI 3.0.11,
but it is probable that this will change at some point for LibFFI.
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.
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?
Make the "install" project depend on the glib-compile-resources gresource
projects so that these tools will be indeed installed. Missed that in my
last commit-oops.
Also make the "install" project not to depend on the testglib project as:
-the test program in the project is not an exhausive test of the GLib
libraries
-One may want to use the project to compile different test program(s), so
it might be better to keep the project but not "install" the resulting
.exe
Add projects to build the glib-compile-resources and gresource(-tool)
utilities, and "install" these tools upon successful compilation, and dist
the new projects.
One piece of note: will it be better to dist gconstructor_as_data.h instead
of generating it in the VS build process (I generated it in the property
sheet update in this commit)?
Visual C++ 2010 projects will follow shortly.
Link to zlib1.lib for release builds and zlib1d.lib for debug builds-
this is to be consistent across the board for the GTK+ stack (and many
other opensource code linking to the ZLib DLL on Windows)
Get rid of _CRT_SECURE_NO_WARNINGS and _CRT_NONSTDC_NO_WARNINGS
from the preprocessor definitions as those two macros are now defined
in msvc_recommended_pragmas.h, which is force-included in these projects
via the property sheets. This will silence C4005 warnings on macro
redefinition.
-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.
-Added glib/ghmac.h to the list of files to copy during the "install" stage
-Cleaned up a bit (glib-2.0->glib-$(ApiVersion), where $(ApiVersion) is
2.0)
This relates to my previous commit titled "add a script to generator
files for building" on behalf of Shixin Zeng.
Tell people about the availability of a python script to create the
necessary files for a Visual C++ build from a GIT checkout.
This is done with the courtesy of Shixin Zeng's python script which does
the job and eliminates the troubles of getting a suitable shell environment
to do the "make dist" job (which is especially not easy on Windows itself!)
-In gio/Makefile.am, the name for one of the filters for capturing the
sources for the GIO VS Project Files is corrected.
-Remove the GIO source file items in the VS project files templates as
a result for this change, and move the entry of the "new"
gregistrysettingsbackend.c into the filter in gio/Makefile.am
This time I realized that I needed to set autocrlf=false on my Windows side
... ugh...
This is one of those files that must have CRLF line endings to work
orrectly :|
-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.
-Seperate intermediate directories for each project to avoid intermittent
MSBuild errors that a build log cannot be written while in use, and
update the property sheet as necessary.
-Minor cleanups of uneeded tags in the projects/properties
These tools require the use of GModule headers also, so update the include
directories so that the correct gmodule.h will be included instead of the
system-installed version.
-Added projects to compile the glib-compile-schemas and gsettings utilities
-Update .vsprops to install these in "install" phase
-Distribute these projects also
-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!
These are the updates to the autotools files to
ensure the expansion of the GIO, GLib and GObject
project files (*.vcxproj, *.vcxproj.filters) and to
enable the distribution of the VS2010 project files
The actual VS2010 project files will follow shortly
Due to changes in the GIO APIs/headers, the glib.vsprops
is updated to reflect that in the "install" phase, namely:
-removal of the gperiodic.h header
-addition of GPollable I/O Stream, GTCP Connection and
GTLS headers
-Made up for missed header files in glib and gio during "install"
-Added macro necessary for GLib/GModule .def generation under Win64
-updated location of getting glibconfig.h.win32 for building
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
It sucks to have the lists of public headers duplicated in the
Makefile.am files and the glib.vsprops file. But it isn't exactly easy
to work around all the weirdness in autotools, Visual Studio, and bat
files either to do it another way.
Correspond to GUnixInputStream and GUnixOutputStream. No true async
support though. But that is how the Win32 API is, for files not
explicitly opened for so-called overlapped IO.
The API to create these streams takes Win32 HANDLEs. Not file
descriptors, because file descriptors are specific to the C library
used. The user code and GLib might be using different C libraries.
Also add a test program for the new classes, and a gio-windows-2.0.pc
file.
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.
2009-01-13 Tor Lillqvist <tml@novell.com>
* win32/vs8/README
* win32/vs9/README: New files. Mention this VS solution and
projects are experimental and that https://code.launchpad.net/oah
might be a better choice.
* win32/vs8/Makefile.am
* win32/vs9/Makefile.am (EXTRA_DIST): Add the READMEs and two
missing vcproj files.
svn path=/trunk/; revision=7806
2008-11-02 Tor Lillqvist <tml@novell.com>
Bug 558153 - Patch for .def files generation
* win32/{vs8,vs9}/*.vcproj: Add " around paths, making it
possible to compile in a directory containing spaces. .def files
generation is done for every configuration not only the "Debug"
ones.
Patch by Guillaume Duhamel.
svn path=/trunk/; revision=7639
2008-09-16 Tor Lillqvist <tml@novell.com>
* win32/vs9: New folder. Project files for use with MSVS9. Based
on the MSVS8 project files is win32/vs8. Four configurations:
Debug|Win32, Release|Win32, Debug|x64 and Release|x64. DLL names
simplified to of the style glib-2-vs9.dll.
svn path=/trunk/; revision=7497
2008-09-15 Tor Lillqvist <tml@novell.com>
* win32/vs8/*.vcproj: Drop the "win32" part from under
"dependencies" so that the same project files can be used also
for 64-bit compilation by just having a different
"dependencies" folder containing 64-bit packages instead. At
least, I hope it will work out some way like that. MSVS
project files really are a pain to maintain. Much information
is typically copied for four different configurations
"Debug|Win32", "Release|Win32", "Debug|x64" and "Release|x64"
instead of having common stuff listed just once and only different
parametrisations. Or am I missing something?
Make the "Release" configuration work, too. Use correct character
set for the gspawn-win32-helper programs. Use correct subsystem
for the non-console one.
svn path=/trunk/; revision=7490
2008-09-15 Tor Lillqvist <tml@novell.com>
* win32/vs8/*.vcproj: Don't use Detect64BitPortabilityProblems
as those warnings are misleading. They don't take into
consideration ifdefs in glibconfig.h and elsewhere for _WIN64.
svn path=/trunk/; revision=7488
2008-09-15 Tor Lillqvist <tml@novell.com>
* win32/vs8/gobject.vcproj
* win32/vs8/gthread.vcproj: Drop G*_EXPORTS from
PreprocessorDefinitions, nothing looks for such
macros.
svn path=/trunk/; revision=7486
2008-09-15 Tor Lillqvist <tml@novell.com>
* win32/vs8/glib.vcproj: Add DLL_EXPORT to export also the
GLIB_VAR variables that aren't mentioned in glib.symbols.
svn path=/trunk/; revision=7485
2008-09-15 Tor Lillqvist <tml@novell.com>
* win32/vs8/*.vcproj: Update to match the Makefile.am files. Drop
G*_EXPORTS from PreprocessorDefinitions, nothing looks for such
macros. Add G_DISABLE_DEPRECATED. Add PCRE_STATIC for glib to
avoid exporting the pcre functions. Add G_LOG_DOMAIN for gobject.
svn path=/trunk/; revision=7484
2008-08-27 Tor Lillqvist <tml@novell.com>
* win32/vs8/*.vcproj: Add "win32" directory level to the
references to the dependencies folder (which each actual user of
the project file probably needs to edit anyway depending on their
directory structure). Add missing files, remove nonexistent files.
svn path=/trunk/; revision=7404
2008-08-27 Tor Lillqvist <tml@novell.com>
* win32/vs8/glib.vcproj: Handle also G_GNUC_FORMAT in the
custom build step for glib.symbols.
svn path=/trunk/; revision=7402
2008-08-27 Tor Lillqvist <tml@novell.com>
* win32/vs8/glib.vcproj: Don't needlessly copy localcharset.c, but
compile it where it is in libcharset. Add "win32" directory level
to the references to the dependencies folder (which each actual
user of the project file probably needs to edit anyway depending
on their directory structure). Drop the nonexistent gi18n.c
file. Drop dirent as gdir.c includes dirent.h and wdirent.c
directly.
svn path=/trunk/; revision=7401
2008-08-02 Tor Lillqvist <tml@novell.com>
Bug 545954 - 64-bit issue in dirent
* win32/dirent/dirent.h: Use __int64 for the dd_handle on 64-bit
Windows. (Would use intptr_t, but that is not available before
MSVS8, and we want to keep this compilable also with MSVS6 and 7,
I think.) Thanks to Richard Hult.
svn path=/trunk/; revision=7286
2008-05-19 Tor Lillqvist <tml@novell.com>
* win32/dirent/dirent.c: Include dirent.h with doublequotes so
that it is searched from this same folder first.
svn path=/trunk/; revision=6914
2008-05-19 Tor Lillqvist <tml@novell.com>
* win32/vs8/gspawn-win32-helper.vcproj
* win32/vs8/gspawn-win32-helper-console.vcproj: New files. Build
these two executables.
* win32/vs8/*.vcproj: Compile as C and not C++.
* win32/vs8/glib-genmarshal.vcproj: Use MBS and not Unicode. (What
this setting really means is just that we don't define the UNICODE
and _UNICODE macros when compiling; it has no effect on what APIs
the code might use.) Use the same IntermediateDirectory as the
other projects.
* win32/vs8/glib.sln: Add the gspawn-win32-helper and gspawn-win32-helper projects.
svn path=/trunk/; revision=6911
2008-05-17 Tor Lillqvist <tml@novell.com>
* "build" is no longer include into GLib through
svn:externals. The relevant directories and files have been svn
add'ed to GLib (trunk) instead.
svn path=/trunk/; revision=6895
