bug-gnulib
[Top][All Lists]
Advanced

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

Re: Why does gnulib use makefile rules rather than configure?


From: Paul Smith
Subject: Re: Why does gnulib use makefile rules rather than configure?
Date: Mon, 16 Sep 2019 16:47:29 -0400

On Sun, 2019-09-08 at 16:40 -0700, Paul Eggert wrote:
> Admittedly GNU Make is a special case, since you want to build it
> without having 'make'. And if it's just a few Gnulib modules and
> they're not doing anything fancy, perhaps we can modify the modules
> to use 'configure' substitutions instead of 'make' rules.

I enhanced GNU make's build.sh to be fancy enough to manage some basic
substitutions, which are good enough for the current suite of gnulib
modules.  We'll see what happens in the future!

I recognize there are some situations where make snippets are really
the best way, but it seems like they're being used even in places where
configure.ac would be just as simple.  I think it would be a good
"statement of policy" for gnulib that if there are equivalent ways of
handling it, configuration.ac should be preferred over Makefile.  I
understand I'm probably the only person who cares.

> On the other hand perhaps it's time to stop worrying about building
> GNU make without a 'make'. We don't worry that GCC can't be built 
> on a system without a C compiler, so why worry about building GNU
> Make on a system without 'make'?

Well, IMO the two situations are not comparable: no one would expect a
C compiler to be written in (for example) assembly (and anyway what
would your assembler be written in... maybe sh?!?! :)).

I take your point but I daresay that if GCC had managed to not require
a C compiler to build itself, somehow, they would surely be unhappy
about ditching this very useful capability in order to satisfy gnulib
module builds :).

Similarly I'm loathe to ditch this "make-less build" capability for GNU
make unless/until there's no alternative.





reply via email to

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