GNOME Bugzilla – Bug 722047
drop makefile.msc?
Last modified: 2017-07-10 10:27:43 UTC
I was trying to build glib using nmake recently and I noticed that our makefile.msc.in files are hilariously out of date -- they contain files that have long since moved to deprecated/, for example. Since nobody appears to care about these (or to be updating them) perhaps we could remove them? My understanding is that the visual studio project files are the only way to build GLib on MSVC these days (ie: MSBuild).
Ping?
They are supposed to work for all msvc versions and are usually a little more updated on my local machine. Actually I have something compiling on my glib-2-28 branch as well as e.g. glib-2-36 (just fixed including the righ handling of deprecated/) The latter does not work though with: ** GLib-GObject:ERROR:gtype.c:4330:???: assertion failed: (static_quark_type_flags) This is probably due to G_DEFINE_CONSTRUCTOR not working as expected with MSVCRT.lib(cinitexe.obj) : warning LNK4078: multiple ".CRT" sections found with different attributes (C0300040) And I have no idea how to fix that. BTW: for some of the stuff in my glib-2-36 branch I'd like to get some review before pushing. What's the currently preferred way to ask for feedback? To give you an impression of the changes made following the --oneline log: 4a6eae4 msvc: export deprecated symbols b350fc2 win32: proper check for _MSC_VER cdf226c win32: fix msvc makefiles ee6c6cb win32: thread init for static GLib build 2a8742e win32: G_HAS_CONSTRUCTORS needs extra pragma with msvc6 fd116ec win32: msvc6+ build update for glib-2-36 61660f6 win32: build/win32 update for gtk3 and ffi 3082af6 Don't use deprecated g_date_days_in_month() 283d9b8 win32: avoid conversion from unsigned __int64 to double not implemented ddb1c4c win32: conditional use of _stat32 and _wstat32 afa506f Protect inclusion of unistd.h with HAVE_UNISTD_H e225bf0 win32: define _WIN32_WINNT 0x0501 for HW_PROFILE_INFOA 6a85c78 win32: Don't use G_DEFINE_TYPE_WITH_CODE without code
It seems like the .sln-file approach has definitely taken over. If there are no objections, I’m tempted to drop the nmake approach soon, since it seems to have been unmaintained for ~10 years now. https://wiki.gnome.org/Projects/GTK%2B/Win32/MSVCCompilationOfGTKStack#GLib
And then there's also the meson build on the horizon (wip/meson branch, bug #783683).
Created attachment 354828 [details] [review] build: Drop nmake/MSC build system for GLib It hasn’t been seriously maintained for the best part of 10 years and is very outdated. The recommended way to build GLib on Windows is now Visual Studio: https://wiki.gnome.org/Projects/GTK%2B/Win32/MSVCCompilationOfGTKStack#GLib Signed-off-by: Philip Withnall <withnall@endlessm.com>
Here’s a patch which attempts to drop the MSC stuff without breaking anything being used by the VS build system. Chun-wei Fan, does that look correct? Is there anything else from the old MSC build system which we can drop?
Review of attachment 354828 [details] [review]: Hi Philip, I think this patch looks alright to me. Just one nitpick about README.win32 which I noted as below--I think we are good to go after this. Thanks! Also, many, many thanks to Hans for coming up with the NMake Makefiles which paved the foundation along with Tor and other people who had GLib building and running on Windows, under either Visual Studio or GCC! With blessings, thank you! ::: README.win32 @@ +1,1 @@ +Tor Lillqvist <tml@iki.fi> Sorry, I couldn't find a better place to put this review for this file... Can we have this committed with DOS/Windows (CR/LF) line endings? Thanks!
Thanks for the review. I re-fixed the line endings in README.win32 using unix2dos and have merge the patch. I’ll follow up with a commit to add a gitattributes file setting `text eol=crlf` for README.win32, as per https://git-scm.com/docs/gitattributes. Attachment 354828 [details] pushed as a131134 - build: Drop nmake/MSC build system for GLib