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

[Paul Smith]

On Sun, 2022-06-26 at 08:41 +0300, Eli Zaretskii wrote:
> It is sad that Gnulib maintainers aren't prepared to cater to a GNU
> project, and an important one such as Make.  These are special
> requirements that only a handful of GNU project could ever have, and
> for good reasons, so supporting their needs should be a no-brainer.

I suspect their position is that it IS a no-brainer, but with exactly
the opposite result: this requirement is needed by exactly one project
(GNU make, since once you have it you're all set) and so undertaking
all that work in gnulib is not resource-effective.

> > 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.
> 
> #2 would require that we promise to have Make 4.3 available from here
> to eternity.  Is that feasible?

Well, it doesn't have to be GNU make.  It just needs to be some make
that can use automake generated makefiles.  However, it does require
that such a make exists.

There are two different situations: first, bringing up GNU make on a
non-GNU system where you have some make, but not GNU make.  Maybe you
have BSD make or something.  Then the question is, is your existing
make capable of using automake-generated makefiles?

Second, you might be bootstrapping an entirely new system without ANY
make at all.  Now you need to get one.  I don't know whether the other
versions of make available have facilities to build without an existing
make.  Here you might need an older version of GNU make which has a
build.sh.  Of course here you likely already have a cross-build
environment so you could just cross-compile make as well.

> Can you list the Gnulib functions we currently use?

You can find them in the bootstrap.conf file:

https://git.savannah.gnu.org/cgit/make.git/tree/bootstrap.conf

See the list at the end.

The newly-added strtoll() is causing the proximate issue because it
relies on unistd.h which generates an enormous sed script in the
makefile.

This really came up because I was trying to find a way to include the
latest gnulib globbing library.  Adding "glob" to this pulls in a HUGE
number of prerequisites.  But even after undoing this I discovered
strtoull() is bad enough.

My idea was to keep the current glob/fnmatch to use on systems which
couldn't run "configure" (for example with the build_w32.bat script)
and use the gnulib glob/fnmatch for all systems that could run
configure.

But, configure is not enough: you also need make.  The current build.sh
script contains some minimal amount of magic needed to transform the
simple files we used in GNU make 4.3; see
https://git.savannah.gnu.org/cgit/make.git/tree/build.sh#n69
but making this work for the complex targets is frankly more than I
want to take on.

So then I wondered, why even both with gnulib glob?  Maybe we should
just take ownership of the ancient glob we already have and say, if you
have a system with GNU libc you get the latest, else you get this
basically functional version.

> Perhaps we could then prepare a fake-gnulib module with trivial
> implementations of those functions, which could be used by build.sh
> instead of the real Gnulib functions.

This seems odd to me: I mean, isn't that just replacing gnulib with
what it already is?  The point of gnulib is to provide replacements on
systems that don't provide these.  I don't want to create a new "micro-
gnulib" project.

> (Some Gnulib functions are replacements for those found in every C
> library, and those could be simply ignored in the build.sh build,
> relying on libc to do a reasonably good job.)

Yes, we could say that build.sh can only be used on systems which are
essentially POSIX-compliant and don't need a lot of fixup.

The problem is that the process for "make-less" systems in the past has
been: run configure, then run build.sh.  But we won't be able to use
the environment created by configure in this "new" build.sh, because it
works in tandem with the makefiles.  The generated config.h etc. will
assume lots of things that simply aren't true anymore, since we don't
have make.

So to me this is equivalent to my option #1, don't use gnulib at all
(or at least, use it incredibly sparingly).