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

[Eli Zaretskii]

> From: Bruno Haible <address@hidden>
> Cc: Eli Zaretskii <address@hidden>, Paul Eggert <address@hidden>
> Date: Wed, 16 May 2018 12:03:44 +0200
> 
> I think you are barking up the wrong tree.

I'm not sure.  Make is not like any other GNU package, because it is
one of the basic tools required to build other tools.  IOW, building
Make could be part of bootstrapping a GNU environment on a platform
where it was never done before.

That is why GNU Make includes shell scripts such as build.sh, even for
Posix hosts.  The ports of Make to non-Posix hosts simply don't
support anything except the build,sh-like script, that's all.

So let me turn the table and ask you how can GNU Make be built on a
Posix-ish system that lacks (or might lack) glob and/or fnmatch, if
those are imported from Gnulib?

> The step that you underestimate here is "you merely had to
> create a pre-defined config.h file for such a target". Gnulib-generated
> header files (such as glob.h) use many more autoconf tests (such as
> whether a function exists, is declared, has specific bugs). If someone
> tries to create a config.h file by hand for an exotic platform, not
> only will it be time-consuming (the gettext-tools config.h.in for example
> has more than 400 results of configure findings), but also mistakes will
> show up as compilation errors. (This is the downside of the many features
> gnulib has:
>   - C++ support,
>   - support for many platforms,
>   - using the function name 'rpl_foo' if and only if 'foo' would collide
>     with system-provided 'foo'.
> The downside is that wrong guesses for the HAVE_* symbols lead to
> compilation failures more quickly.)

All this is true, but Paul is concerned only by a few specific
platforms, and about a single programming language.  So the above
features are mostly irrelevant in the case in point.

> Really, the approach of maintaining a config.h for a particular platform
> by hand is outdated.

Nevertheless, GNU Make uses it to this day.  It works for Make because
the package is in stable state, and the amount of commits that
introduce new features is very small.  Given the age of Make and the
amount of packages out there that depend on its features, it is
extremely unlikely that this situation will ever change significantly.
So the amount of effort needed to maintain a config.h is very small,
almost negligible.

> > On systems that aren't POSIX and don't have ready access to sed or
> > similar tools
> 
> On such systems the essential step is to create the set of tools that
> are needed to be able to run configure scripts. This includes a POSIX-like
> shell, the coreutils, grep, sed, and maybe awk.

That's not enough.  One also needs to tweak the configure script to
DTRT on such platforms.  As someone who did this very job for Emacs, I
can tell you that it could be a non-trivial job, although it probably
will be simpler for Make than it was for Emacs.