> From: Paul Eggert <egg...@cs.ucla.edu> > Date: Wed, 11 Apr 2018 13:22:32 -0700 > > Except for VMS, GNU Emacs is in a boat similar to GNU Make. It uses > Gnulib (but not Automake), it is buildable on MS-Windows and does not > need Cygwin, it has its own configuration batch script for MS-Windows > (and MS-DOS!).
Actually, Emacs on Windows uses the same configure script used on Posix hosts, it stopped using its own batch file several years ago. (The MS-DOS build does still use a batch file and a bunch of Sed scripts.) For that, the Windows build requires a working installation of MSYS, which is a fork of Cygwin specifically tailored to building MinGW programs using the Posix configury. > So I would look to Emacs for inspiration here. I'm mostly > responsible for the Emacs Gnulib usage and can help and/or answer > questions in this area. First, the job of switching Emacs on Windows to using the normal configury was nowhere near trivial, it required some adaptations, mainly due to the fact that Emacs provides its own emulations of Posix APIs, which the configure script cannot detect, for obvious reasons. I'm guessing this will be a much smaller job in the case of Make, but it still will need to be done. More importantly, Make is somewhat special: it is one of a couple of "basic" utilities which need to be built without a functional Posix environment, in order to "bootstrap" the development environment. This is why Make has simple build scripts for all supported systems, not just on Windows. It's just that on Windows no one bothered to provide or support the alternative of using Autoconf, that's all. Since Make is a much smaller program than, say, Emacs, and its development rate is much slower, the batch file is "good enough": it and the related config.h file need changes only rarely. And I don't think MSYS supports MSVC, at least not out of the box. For these reasons, I wouldn't suggest switching to MSYS/configure kind of build unless all the other alternatives are much worse. Make is a different package, with different needs and very different scale, so the Emacs experience is not necessarily exactly applicable to Make. I didn't try comparing Gnulib's glob.c and fnmatch.c with what's now in GNU Make -- are the differences really so significant as to disallow any attempt of a simple incorporation of changes from Gnulib in just those 2 files? If not, such a "merge" could do the same job much easier, without requiring Paul Smith to import all the Gnulib dependencies, switch to MSYS for the MS-Windows build, and do something else for VMS.