[Top][All Lists]
[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
Re: [Automake-NG] Can we require GNU make >= 3.81? (make memoization doesn't work with GNU make 3.80), Akim Demaille, 2012/05/21
- Re: [Automake-NG] Can we require GNU make >= 3.81? (make memoization doesn't work with GNU make 3.80),
Stefano Lattarini <=