| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Stop ignoring warnings C4251, C4273 and C4275 and add /EHsc in the compiler
flags, so that we know if we are inadvertedly tying ourselves too closely to
a Visual Studio compiler/STL version
|
| |
|
|
|
|
|
| |
So we can use the 2.66 version numbers for stable releases in the
glibmm-2.4 ABI series.
We've done similar ABI name changes several times before.
|
| |
|
|
|
|
|
|
|
| |
To make things more consistent and less prone to confusion, if 'USE_MESON_LIBS'
is specified in the NMake command line, build the DLLs and .lib's that are
named like the Meson counterparts. Binaries built with Meson+Visual Studio
and the ones that are built via NMake using 'USE_MESON_LIBS' are
interchangeable, provided that they are built with the same Visual Studio
version.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
So we can use the 2.64 version numbers for stable releases in the
glibmm-2.4 ABI series.
We don't need to release a stable ABI-parallel glibmm until we need
to release gtkmm 4.0, and that won't happen until GTK 4.0.0 happens.
We've done similar ABI name changes several times before.
|
| |
|
|
|
|
| |
Make sure that we are defining GIOMM_API as __declspec(dllexport) when
building giomm and so stop the use of gendef.exe. We are now ready to
drop gendef from the glibmm sources.
|
| |
|
|
|
|
|
|
|
|
|
| |
Clean up the build files a bit and update the glibmmconfig.h.[in|meson] so that
we use __declspec(dllexport) when GLIBMM_BUILD is defined (i.e. during the
build of glibmm) on Visual Studio.
Also, for the meson builds, disable warnings 4251 and 4275 as they all relate
to building DLLs regarding symbol export, which is harmless as we know clearly
that we are indeed building DLLs in our case, and we have already set
GLIBMM_API appropriately
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
...from a GIT checkout, from the various .ccg/.hg and the *.[cc|h].m4 sources,
as well as the wrap_init.cc sources. This will obviously require PERL, as well
as a Cygwin or MSYS installation that has a working m4 executable for Windows
for this to work. Note that release tarballs continue to build on Visual
Studio as they did before, without the need for PERL nor m4.
Note that this does not yet support generating [glib|gio]mmconfig.h nor
[glib|gio]mm.rc from their .in counterparts, as well as tools\gmmproc
and tools\generate_wrap_init.pl, which will be done in a later commit.
|
| |
|
|
|
|
|
|
| |
Since this is entirely buildable by Visual Studio, build it as well and see
whether we can use this to allow builds from GIT checkouts for other -mm
libraries with MSVC builds.
Copy this .lib and its header upon 'install'.
|
| |
|
|
|
|
| |
libsigc++'s Meson build files have been corrected to produce
sigc-3.0.lib like the autotools builds, so make sure we link to the
correct .lib file.
|
| |
|
|
|
|
|
| |
This reduces the likelihood of accidently mixing binaries linked to
different CRT versions within a single build tree.
Also, fix up building the tests as new tests were added along the way.
|
| |
|
|
|
| |
This allows one to use C++ dependencies built using Meson in an easier
way, as applicable.
|
| |
|
|
|
|
|
|
|
| |
So we can use the 2.62 version numbers for stable releases in the
glibmm-2.4 ABI series.
We don't need to release a stable ABI-parallel glibmm until we need
to release gtkmm 4.0, and that won't happen until GTK 4.0.0 happens.
We've done similar ABI name changes several times before.
|
| |
|
|
|
|
|
|
|
| |
So we can use the 2.60 version numbers for stable releases in the
glibmm-2.4 ABI series.
We don't need to release a stable ABI-parallel glibmm until we need
to release gtkmm 4.0, and that won't happen until GTK 4.0.0 happens.
We've done similar ABI name changes several times before.
|
| |
|
|
|
| |
* MSVC_NMake/config-msvc.mak: This file was forgotten in the previous
commit that changed the ABI name.
|
|
|
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
|
