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.


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:


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

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.

Reply via email to