bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: Re: Goodbye to GNU make's "build.sh" ... ?
Date: Sun, 26 Jun 2022 17:39:41 +0300

> From: Paul Smith <psmith@gnu.org>
> Date: Sun, 26 Jun 2022 10:11:12 -0400
> 
> > 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.

OK, thanks.  The list is very short.  And I think most if not all of
the functions there can be stubbed out.  For example, strtoll can be
stubbed by a trivial wrapper around strtol, mempcpy can be easily
implemented using memcpy, and getloadavg and glob could be replaced by
functions that return trivial results, since building Make doesn't
really need those functions, does it?

> > 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?

No, because we only need this to build the initial binary of Make,
which then could be used to build the full version, and that full
version will use Gnulib.  So the idea is to create a small file with
trivially simple implementation for functions that might be missing,
and for the rest rely on libc -- just for the first "stage-1",
so-to-say, binary of Make.  Then "stage 2" will use this stage-1
binary to configure and build the full version which uses Gnulib.

> The point of gnulib is to provide replacements on systems that don't
> provide these.

That's not the only purpose, perhaps not only the main one.  The main
one (AFAIU) is to replace library functions with versions that are
either devoid of known bugs or are more compatible to Posix and glibc.

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

I think it's more than that: to build Make we need much less than full
Posix compliance.

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

I thought of making build.sh compile and link make without any
configure step, similar to what build_w32.bat does.

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

No, I'm talking about not using Gnulib only for stage-1 build, the one
that produces a Make binary capable of building the full version.  I
was not talking about avoiding to use Gnulib for the final build whose
results are installed.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]