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: Paul Smith
Subject: Re: Goodbye to GNU make's "build.sh" ... ?
Date: Sun, 26 Jun 2022 15:06:36 -0400
User-agent: Evolution 3.44.1 (by Flathub.org))

On Sun, 2022-06-26 at 17:39 +0300, Eli Zaretskii wrote:
> > 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.

This is sort of what Sven was suggesting.  It could work, but configure
does a lot of things: not only does it generate a config.h but it also
finds compilers, figures out what options they accept, etc.  Obviously
we don't need to do all that for a minimal build, but still the Windows
ecosystem is much simpler because it's so homogeneous; even then
build_w32.bat doesn't support building with Clang for Windows, for
example.  Generating a config.h on any random system is much harder
than having one pre-defined for the Windows32 API.

The goal of this "mini-make" must be to be able to compile automake-
generated makefiles (since that's what's needed in order to work with a
gnulib-enabled system).  Or at least, the Makefile.am that GNU make and
its gnulib modules use.

Since POSIX make does support wildcard syntax (e.g., "foo: *.c" is
legal) we would need glob/fnmatch of some sort, unless we can guarantee
that automake won't use it, for example.

We can hopefully disable other advanced features such as ar parsing,
job control, etc. which will certainly help simplify things.

There's some amount of disingenuity here since make is really just the
top of the iceberg when it comes to bootstrapping: you can't run
configure without a full libc, compiler, coreutils etc. and how can you
build those without a make?  So either we're talking about cross-
compilation, or else this "minimake" would need to be sufficient to
build more than just make itself.



reply via email to

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