Re: Gnulib on Windows (native / mingw32) / VMS / etc.

[Eli Zaretskii]

> From: Paul Eggert <address@hidden>
> 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.