I'm trying to decide what the future is for GNU make's "build.sh" bootstrapping script. As you may recall, this script is provided to allow GNU make to build on systems which don't already have an instance of make installed. Its goal is to build the first make binary, without of course all the fancy parts of avoiding rebuilds, generating dependency files, etc.
Unfortunately, this really cannot work if GNU make is going to rely on gnulib, because a MANY gnulib modules require not only autoconf to work, but also automake. That is, it's not enough to just run configure and then you get a set of source files and header files that you can compile by hand by just invoking the compiler. You must ALSO run make, because the modules provide makefile recipes that invoke sed, etc. to convert files into their final form. I had a discussion about this with the Gnulib maintainers a while ago: https://lists.gnu.org/archive/html/bug-gnulib/2019-09/msg00041.html However the gnulib maintainers were disinclined to modify the practices of the gnulib modules. This leaves me with two options: 1. Stop using gnulib, or at least sharply limit the modules we will include to those with trivial-enough configurations. 2. Abandon the build.sh script and require an existing make program in order to build a new version of GNU make. #1 is what I followed for GNU make 4.3, which has a limited subset of carefully-chosen modules. However this becomes harder over time. For example any module that needs unistd.h requires a very complex automake rule. If #2 is chosen, then a bootstrap process would involve first obtaining an older version of make, such as GNU make 4.3 or lower, and building that with its build.sh, then using the resulting make to build the newer version. I'm interested in thoughts about these options.