Re: Goodbye to GNU make's "build.sh" ... ?

[Sven C. Dack]

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.