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).