[Top][All Lists]

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

Re: Future plans for Autotools

From: Nick Bowler
Subject: Re: Future plans for Autotools
Date: Mon, 25 Jan 2021 17:48:43 -0500

On 2021-01-25, John Calcote <> wrote:
> On Mon, Jan 25, 2021 at 12:26 PM Nick Bowler <> wrote:
>> On 2021-01-25, Zack Weinberg <> wrote:
>> > I'm not at all familiar with Automake's internals, but the reason I
>> > suggested taking advantage of GNU make extensions was the potential
>> > for _complexity_ reduction of the generated Makefile, not performance.
>> > For instance, this generated rule from one of my other projects [...]
>> To be honest if Automake-generated files only worked
>> for users with, say, sufficiently modern versions of GNU Make, I'm
>> not sure there would be any point in using Automake.
> I'm not sure I see your point Nick. Why use Automake? Because I'd much
> rather write (and maintain) two lines of automake code than even a single
> page of GNU make code.

I'm trying to say that if you are going to force users to use GNU make
anyway then then I think most if not all of Automake's features would be
more effectively implemented by one or more "include"-able GNU make
snippets rather than using a standalone perl-based preprocessor stage
like Automake that introduces its own unique set of problems.

This approach is very typically used in the BSD world, where the build
environment is centered around one specific make implementation and
everyone shares the same set of common build recipes.

But for me, I want my packages to be widely portable and out-of-the-box
compatibility with default "make" implementations, to the greatest
extent possible, on a wide variety of real-world platforms is important.
I personally don't want to ask users of non-GNU systems to install GNU
make just because the Makefile would be slightly easier to write.  Today,
I use Automake to help me achieve this goal.  If a new version of
Automake were to make that impossible, because its own rules will not
run on other makes, then I suppose I would not be using that version.

This doesn't mean everything needs to work _perfectly_ on every make,
but I expect at least "./configure --whatever-options && make install"
to work everywhere, and for incremental rebuilds to work contingent on
functional dependency tracking (which in practice is almost everywhere).


reply via email to

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