| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
This fixes the build process so that we won't need to generate them
unnecessarily (i.e. when building from a release tarball built with autotools).
Also streamline the build process that we no longer need to explicitly run
the 'prep-git-build' target before building, where we generate
[glib|gio]mm[config.h|.rc], and if needed, gmmproc and generate_wrap_init.pl,
as part of the normal 'all' target if necessary
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the built DLL and .lib's contain the toolset version if the build is
carried out using Visual Studio 2017 or later, unless the
'msvc14x-parallel-installable' option is set to be false during configuration.
The reasoning behind this change is that there are subtle problems when, for
instance, one tries to link to a Visual Studio 2017-built glibmm when building
gtkmm and libxml++ with Visual Studio 2019. This is unfortunate as
Microsoft did try hard to make interoperating between binaries built with
Visual Studio 2015, 2017 and 2019 as easy as possible in terms of ABI and API,
but unfortunately this hits the corner cases where this compatibility does not
work.
As the name suggests, this attempts to make Visual Studio 2017 and 2019
builds share a single set of underlying C DLLs easier, while avoiding breakages
caused by such subtle differences.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This updates the build to use the toolset version in the final DLL
and .lib filenames, similar to what is done in Boost, instead of
the Visual Studio version.
This means that by default, we will use 'vc141' instead of 'vc150'
in Visual Studio 2017 builds, and 'vc142' instead of 'vc160' in
Visual Studio 2019 builds.
If using the former naming is desired, use 'USE_COMPAT_LIBS=1' in
the NMake command line, albeit all such binaries will now be named
with 'vc150' in the DLL and library bames
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds rules to the NMake Makefiles so that they can find the sources under
$(srcroot)/untracked, and thus will not need to re-generate the sources.
However, for builds from such tarballs, it is necessary to do
'nmake /f Makefile.vc CFG=$(CFG) prep-git-build' so that the resource scripts
and config headers are generated, prior to performing the build.
Please note that glibmm_generate_extra_defs-2.x is now built as a DLL with the
NMake Makefiles as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will enable one to generate the following files:
MSVC_NMake/glibmm/glibmmconfig.h
MSVC_NMake/glibmm/glibmm.rc
MSVC_NMake/giomm/giommconfig.h
MSVC_NMake/giomm/giomm.rc
when building from a GIT checkout.
This will also enable one to generate the following files:
tools/gmmproc
tools/generate_wrap_init.pl
from a GIT checkout or from a source tree unpacked from a release tarball so
that one can use these to build directly from a GIT checkout using NMake,
or to have gmmproc and generate_wrap_init.pl ready to use to build other
-mm libraries.
|
|
|
|
|
|
|
|
| |
...so that one may be able to use these in the future for other -mm packages.
Also update the header installation as they could have been generated during
the build. Update README.win32 to indicate building from a GIT checkout is
better supported, and how one may carry this build out.
|
|
|
|
|
| |
This allows one to use C++ dependencies built using Meson in an easier
way, as applicable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a set of NMake Makefiles which can be used to build glibmm
with Visual Studio 2017 and later. This will supersede the Visual
Studio 2017 project files, as this approach will reduce the likelihood
of the Visual Studio build files becoming out-of-date as this also
reads from the various filelist.am's under glib/ and gio/.
The existing gendef, and generated [glib|gio]mmconfig.h and generated
[glib|gio]mm.rc will continue to be used.
The NMake Makefiles will now be distributed instead of the Visual Studio
project files from this point on.
The Visual Studio project files will be removed in the next commit
|
|
|
|
|
|
| |
This prepares for the transition to using NMake Makefiles for building
glibmm, rather than the Visual Studio project files, to ease future
maintenance.
|
|
|
|
|
| |
Let people know that libsigc++-3.x is required, and for Visual Studio
builds, Visual Studio 2017 is required.
|
|
|
|
|
|
|
|
| |
The information in there regarding Visual Studio builds needs to be
up-to-date, especially as we dropped support for Visual Studio 2012 and
earlier, so update the info. It is no longer necessary, nor is it
recommended, to use the /vd2 option with later Visual Studio versions, as
it causes the code to be built incorrectly and causes crashes.
|
|
|
|
|
|
| |
2006-04-07 Cedric Gustin <cedric.gustin@gmail.com>
* README.win32: Updated for Mingw-4.1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
2006-04-06 Cedric Gustin <cedric.gustin@gmail.com>
* MSVC_Net2003/*.vcproj: Embed the manifest file into executables
in the case of the Debug target.
* README.win32: Fixed a few typos.
* build_shared/Makefile_build.am_fragment: Add -DGLIBMM_BUILD to
the extra_defines compiler flags (switch between
dllexport/dllimport on win32).
* glib/glibmmconfig.h.in: Define GLIBMM_DLL when building with
mingw32/cygwin. This makes the GLIBMM_API tag (and GTKMM_API for
gtkmm) active with these two platforms, as required by bug
#309030.
* glib/glibmm/object.h, glib/glibmm/objectbase.h : Tag the Object
and ObjectBase classes with GLIBMM_API to make Visual Studio happy.
|
|
|
|
| |
fixes, allowed during the hard code freeze.
|
|
|
|
|
|
|
|
|
|
|
| |
2004-01-27 Cedric Gustin <cedric.gustin@swing.be>
* build_shared/Makefile_build.am_fragment: Added win32-specific
--export-all-symbols to linker flags. This is backported from
gtkmm-2.2.
* README.win32: Updated text for glibmm-2.4.
* tools/generate_wrap_init.pl.in: Replaced GTKMM_WIN32 by the
standard G_OS_WIN32.
|
|
|
|
|
|
|
|
|
| |
2003-09-27 Cedric Gustin <cedric.gustin@swing.be>
* glib/glibmm/threadpool.cc: Removed
_GTKMMPROC_SIGNAL_H_AND_CC(#ifndef G_OS_WIN32) restrictions. These
functions are now implemented in the latest (2.2.4) GTK+ on win32.
* README.win32 : Updated list of unsupported functions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
2003-03-04 Cedric Gustin <cgustin@ibelgique.com>
* configure.in : Removed libstdc++ in LDFLAGS on win32. Latest
libtool is taking care of it.
* build_shared/Makefile_build.am_fragment,
tools/extra_defs_gen/Makefile.am : Added
--export-all-symbols linker flag on win32 (required by latest
libtool to build DLLs).
* build_shared/Makefile_gensrc.am_fragment : Modifiy rule that
builds wrap_init.cc. wrap_init.cc now contains reference to all
objects, event on win32. #ifdefs are included when needed.
* README.win32 : updated for version 2.2. Added list of missing
methods and signals on win32
* tools/m4/base.m4 : Added _GTKMMPROC_SIGNAL_H_AND_CC macro.
|
|
|