automake-ng
[Top][All Lists]
Advanced

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

Re: [Automake-NG] Can we require GNU make >= 3.81? (make memoization doe


From: Stefano Lattarini
Subject: Re: [Automake-NG] Can we require GNU make >= 3.81? (make memoization doesn't work with GNU make 3.80)
Date: Mon, 21 May 2012 13:22:40 +0200

On 05/21/2012 10:50 AM, Akim Demaille wrote:
> 
> Le 20 mai 2012 à 15:11, Stefano Lattarini a écrit :
> 
>> Since GNU make 3.81 has been released by more than six years now, any
>> objection against requiring it as the minimal supported version?  I'd
>> rather not waste efforts on older versions used only by a vanishingly
>> small percentage of the user base …
> 
> No objections from me, of course.  3.81 is widely available.
>
Good, I'll soon apply the patch then.

>> Note that sadly we can't require GNU make >= 3.82 (which would offer use
>> the .ONESHELL feature) because Debian and Ubuntu still comes with GNU make
>> 3.81 as the only version available through the package manager :-(
> 
> Actually, if automake-ng were to require 3.82, it would certainly
> help have 3.82 be more wide spread.  If you were to require 3.82,
> then I would support you.  You can count on me to defend the
> choice of ONESHELL too.
>
> BTW, if we can't require it, then at least I'd like Automake-ng
> to be compliant.  I would feel safer if the test-suite could
> also be run under ONESHELL.
>
A use of .ONESHELL would impact several rules that rely on using different
"subshells" to play nice with "make -n", or to avoid interferences from
earlier environment modifications (mostly changes of directories).  It
would be messy and impractical to try to support both presence and absence
of .ONESHELL in one codebase; we should pick one setup, and stick with it.

And since we still want to support GNU make 3.81, I say we stick to *not*
using .ONESHELL for the moment.  This can be changed when (and if) requiring
a more modern GNU make version is truly worth the price in lost portability
(e.g., if 3.83 is going to introduce built-in variable memoization and
support for a .TARGETS special variable -- akin to .VARIABLES -- we are
definitely going to want to require 3.83 or later ;-)

> And if there are accommodations
> to make to be compliant, then having an automake-ng option
> for ONESHELL should not too expensive to pay.
>
That would basically double the setups that needs to be testsuite-covered ...
I'd rather not go down that road.

> And I'd be quite happy to know what the impact one performances
> are (including on Windows machines where fork is known to be
> very expensive).
> 
I think we wouldn't gain much there; most Automake recipes are
already written as single (backslash-continued) shell command
lines anyway.

Regards,
  Stefano



reply via email to

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