On Sat, Jun 25, 2022, 1:48 PM Paul Smith <psm...@gnu.org> 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 realize it's easy to say and pretty obvious but option 2 from a user
perspective is sort of horrific.


> I'm interested in thoughts about these options.
>
>

Reply via email to