> From: Bruno Haible <br...@clisp.org> > Cc: Eli Zaretskii <e...@gnu.org>, Paul Eggert <egg...@cs.ucla.edu> > 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.
