Hello, developers causing a "Catch 22" paradox is not new. You want to avoid such software, or at least work around it with a big margin. Sharply limiting the use of gnulib here may not provide such a margin and cause repeated trouble in the future. Your condition of "to those with trivial-enough configurations" can fail with the next update to gnulib.
How about a third option: 3. Allow to build a minimal Make executable, which provides basic and traditional Make functionality and does not rely on gnulib, and then use it as a bootstrap. Then make the gnulib maintainers aware of the "Catch 22" and tell them not rely on newer GNU Make versions. Offering a minimal Make executable next to the full GNU Make may also have uses for other projects. -Sven On 25/06/2022 22:47, Paul Smith wrote:
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.