summaryrefslogtreecommitdiff
path: root/MSVC_NMake
Commit message (Collapse)AuthorAgeFilesLines
* NMake Makefiles: Ensure g[lib|io]mm[config.h|.rc] are createdChun-wei Fan2022-05-271-0/+4
| | | | | | | | ...before attempting the build. This will ensure that they are available during the build and that we do not accidentally refer to an old copy that exists on the system. Should fix issue #99.
* NMake Makefiles: Remove rules on build directory creationChun-wei Fan2022-05-272-16/+10
| | | | | | | Instead, create them using plain 'md' commands if they don't exist prior to compiling the sources, if applicable. Should speed up builds a bit.
* Build: Support VS2022 buildsChun-wei Fan2021-11-091-1/+4
| | | | Make these builds distinct from the Visual Studio 2019 builds.
* Clean up Visual Studio build filesChun-wei Fan2021-05-071-2/+1
| | | | | | 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
* Change the ABI to glibmm-2.68Kjell Ahlstedt2020-12-111-1/+1
| | | | | | | 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.
* NMake Makefiles: Use Meson-style DLL and .lib naming if requestedChun-wei Fan2020-07-231-12/+26
| | | | | | | | | 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.
* NMake Makefiles: Fix generating [glib|gio]mm[config.h|.rc]Chun-wei Fan2020-07-223-52/+66
| | | | | | | | | | 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
* NMake Makefiles: Support ARM64 Windows buildsChun-wei Fan2020-07-141-0/+4
| | | | | This will make the NMake Makefiles capable of building ARM64 binaries of glibmm and giomm, which can be used on Windows 10 on ARM systems.
* NMake Makefiles: Clean up building tests and examplesChun-wei Fan2020-06-164-171/+29
| | | | | | | | | | | | | | | | Instead of hand-written rules, just make use of what we have to generate the rules on the fly for most of the tests and examples, since the rules are more or less the same for each of the test and example programs. We only need to single-out the ones that aren't buildable under Windows and those that have multiple programs under each directory, as opposed to one example/test program per directory. Even for those directories that have multiple example programs, we can pretty easily generate the rules for them. Also remove repeated parts that were added by accident. This can shrink the NMake Makefiles by a bit.
* NMake Makefiles: Use Toolset version in DLL names by defaultChun-wei Fan2020-06-162-22/+37
| | | | | | | | | | | | | | 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
* Change the ABI to glibmm-2.66Kjell Ahlstedt2020-03-171-1/+1
| | | | | | | | | 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.
* NMake Makefiles: Fix builds from Meson tarballChun-wei Fan2020-03-111-1/+2
| | | | | | | | For the glib/src/*.[c|h].m4 sources, look also for the generated sources that are in untracked/glib/glibmm, so that we do not needlessly try to generate that file, meaning m4 will be required even in release tarballs. Somehow this did not make it into master but is in glibmm-2-62... :|
* NMake Makefiles: Fix 'install' for Meson tarballsChun-wei Fan2020-03-091-0/+4
| | | | We need to look for headers from untracked/ as well.
* build: Drop gendefChun-wei Fan2020-03-073-114/+0
| | | | | We are now building glibmm without the use of gendef for all builds, so we can now drop gendef from the glibmm sources.
* Visual Studio builds: build giomm without gendefChun-wei Fan2020-03-073-18/+2
| | | | | | 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.
* build: Do not use gendef.exe for glibmmChun-wei Fan2020-03-073-6/+3
| | | | | | | | | | | 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
* meson: Use /utf-8 for Visual Studio buildsChun-wei Fan2020-03-051-1/+1
| | | | | | | | This way, we can avoid warning/error C4819 when building glibmm due to unicode handling issues in the compiler, which is likely to pop up on East Asian locales on Windows. We need to ignore warning C4828 when building gendef.exe though with this.
* MSVC NMake: Allow builds from Meson-generated tarballsChun-wei Fan2020-03-034-7/+27
| | | | | | | | | | | | 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.
* Add support for building glibmm with MesonKjell Ahlstedt2020-03-013-0/+43
| | | | | | glibmm can be built with either Autotools or Meson. See MR !27
* NMake Makefiles: Fix headers installationChun-wei Fan2020-02-271-4/+4
| | | | Fix Copy-n-paste error...
* generate-msvc.mak: Correct path to find gmmproc PERL modulesChun-wei Fan2020-02-271-1/+1
| | | | The GLIBMM_MODULE_NAME should be glibmm-2.x, not giomm-2.x
* NMake Makefiles: Add targets to ease build from GIT checkoutsChun-wei Fan2020-02-264-0/+84
| | | | | | | | | | | | | | | | | | | | 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.
* NMake Makefiles: "Install" gmmproc itemsChun-wei Fan2020-02-261-10/+19
| | | | | | | | ...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.
* MSVC_NMake: Add rules to generate and build sourcesChun-wei Fan2020-02-264-4/+77
| | | | | | | | | | | | ...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.
* NMake Makefiles: build glibmm_generate_extra_defs-2.xx.libChun-wei Fan2020-02-265-2/+21
| | | | | | | | 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'.
* MSVC_NMake/config-msvc.mak: Correct libsigc++ libnameChun-wei Fan2020-02-071-1/+1
| | | | | | 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.
* NMake Makefiles: Split outdir by toolset versionChun-wei Fan2019-12-275-178/+192
| | | | | | | 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.
* NMake Makefiles: Use /utf-8 where availableChun-wei Fan2019-12-261-0/+4
| | | | | | This avoids miscompilations and errors when building under certain locales (Chinese, Korean and Japanese in particular) as the compiler could not handle Unicode sequences properly without this flag.
* NMake MAkefiles: Add USE_MESON_LIBSChun-wei Fan2019-12-262-5/+13
| | | | | This allows one to use C++ dependencies built using Meson in an easier way, as applicable.
* Change the ABI to glibmm-2.64Kjell Ahlstedt2019-09-181-1/+1
| | | | | | | | | 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.
* Change the ABI to glibmm-2.62Kjell Ahlstedt2019-03-171-1/+1
| | | | | | | | | 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: Change the ABI to glibmm-2.60Kjell Ahlstedt2018-11-101-1/+1
| | | | | * MSVC_NMake/config-msvc.mak: This file was forgotten in the previous commit that changed the ABI name.
* build: Remove Visual Studio 2017 projectsChun-wei Fan2018-09-0741-5402/+0
| | | | | This removes the Visual Studio projects as they have been replaced with the NMake Makefiles.
* build: Add NMake MakefilesChun-wei Fan2018-09-0710-47/+772
| | | | | | | | | | | | | | | | 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
* build: Rename MSVC_Net2017 to MSVC_NMakeChun-wei Fan2018-09-0745-0/+5697
This prepares for the transition to using NMake Makefiles for building glibmm, rather than the Visual Studio project files, to ease future maintenance.
View Lorry Controller Status