The obvious end-point of #2 is to add a make-4.3.tar.gz file to future make packages and modify build.sh to unpack and use it. This might involve renaming the "inner" script to "build-4.3.sh" or similar.
But I also have the same question: what are the real-world cases where build.sh is needed? > On Jun 26, 2022, at 10:44 AM, Philip Guenther <guent...@gmail.com> wrote: > > >> On Sat, Jun 25, 2022 at 12: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. > > Can anyone contribute information about actual cases where build.sh was used? > > I've been using GNU make since 1992 or so, on only 9 or so different UNIX > platforms, but they all had _some_ form of make available, however crippled, > that was sufficient to bootstrap GNU make. So, I've avoided being its target > audience. Who has been and can they speak to what they would do without it? > "I have a native compiler, but not make" is kinda a weird place to be; those > bootstrapping a new OS typically cross-compile the entire toolchain until > they can self-host: make is just another small divot in that bumpy road and > using build.sh when they still have to cross-compile the rest of the > toolchain doesn't actually help. > > >> 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. > > Lacking a description of a case in the past where build.sh was actually the > only sane option, I would go with #2. > > > Philip Guenther >
