Re: [Automake-NG] Can we require GNU make >= 3.81? (make memoization doesn't work with GNU make 3.80)

[Stefano Lattarini]

Hi Akim.

On 05/22/2012 11:07 AM, Akim Demaille wrote:
> 
> Le 21 mai 2012 à 13:22, Stefano Lattarini a écrit :
> 
>> 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.
> 
> I'm not sure that there are that many rules that ought
> to be written really differently.
>
I think rules whose recipe would have to be *radically* altered would be
very few (probably none).  But I wasn't concerned with code churn, rather
with potential subtle breakages and confusion.

Oh, and here's another serious issue with .ONESHELL, one I've just thought
of: its use would make it harder to prevent exceeding of command line length
limits.  For example, assume I want to remove the files listed in ten
variables X0, ... X9, and that I know it is very unlikely that any of those
variables expands to a list that can exceed command line length limits,
while their contents taken together is likely to do so; then, if .ONESHELL
is in use, I can't do anymore:

  clean:
      rm -f $(X0)
      ...
      rm -f $(X9)

but I have to resort to:

  clean0: ;rm -f $(X0)
  clean: clean0
  ...
  clean9: ;rm -f $(X9)
  clean: clean9

If GNU make were to provide an option to split recipes at user-selected places
even when .ONESHELL is in use (maybe a seldom-used character like '%', or even
a special macro like '$]' or '$!') the above objection would become moot:

  clean:
      %rm -f $(X0)
      ...
      %rm -f $(X9)

  clean:
      $]rm -f $(X0)
      ...
      $(!)rm -f $(X9)

Do you think it would be worthwhile to open a feature request with the GNU
make maintainers?

> Actually, the very touch rules can be written as a single command to
> avoid such issues.
>
I'm not sure I follow here.  Can you give an example.

> Yet if Automake-ng is not compatible with ONESHELL, it
> prevents the user from using it.
>
This is true.  But that is no regression w.r.t. mainline Automake, so it's
not high priority IMHO; and personally, I believe the real fix would be for
GNU make to allow '.ONESHELL:' to take arguments, that are to be interpreted
as the rules whose recipes are to be run by a single shell invocation.  Again,
do you think it would be worthwhile to open a feature request with GNU make
maintainers?

>> 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 ;-)
> 
> But then, Makefile.am written by users would be broken
> by such a move.
>
Right.  So we'll have to decide about .ONESHELL before doing a stable
release ;-)

>>> 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.
>
> OK.
> 

Regards,
  Stefano