Re: .ONESHELL enhancement?

[Ralf Wildenhues]

* Paul Smith wrote on Sun, Oct 04, 2009 at 07:36:15PM CEST:
> On Sun, 2009-10-04 at 08:26 -0400, David Boyce wrote:
> > One of the bedrock principles of autoconf/automake is that you
> > shouldn't make assumptions about what the target platform looks like.
> > In particular, you can't predict what make version will run the
> > generated Makefile, and thus reliance on nonstandard features is
> > discouraged.
> 
> I think what Ralf is concerned about is that adding .ONESHELL changes
> the behavior of ALL make recipe invocations.  Also, you can
> add .ONESHELL and makes that don't support it won't fail due to syntax
> errors, etc. which is not true of many other GNU make constructs.
> 
> That means that if someone wants to use the features of automake to
> provide a standard framework but still wants to require GNU make for
> their project (it's been known to happen), or just wants to allow GNU
> make to perhaps run more efficiently, they might add .ONESHELL to their
> Makefile.am.  If automake wants to allow this to work correctly, it will
> need to ensure all the automake-generated rules behave properly in
> a .ONESHELL environment.  Most other types of make enhancements don't
> have this problem, since they wouldn't come into play for rules that
> automake generates.

Exactly.  Thanks for explaining it better.

> I guess we have to decide what the ultimate purpose of .ONESHELL is to
> be, since we can't have both goals at the same time: either we want it
> to be solely for performance improvement, in which case adding () (and
> maybe separating them with "&&"?) would be the right thing since
> existing recipes will work without modification (the command line length
> thing is a potential issue but I don't believe adding a few extra
> characters per line is going to make much difference),

It's not the few extra characters that matter.  It's the concatenation
of two or more long command lines that matters.

> Matt McCutchen <address@hidden> writes:
> > The only general fix I can envision for these issues is to wrap every
> > line (after interpretation of \ continuations) in parentheses.
> > Compared to the current approach, this would save execs but not forks.
> > I did a little test on my computer and the exec seems to be the
> > expensive part:

> I tried with something more complex than just "true", in case bash
> itself had some kind of fast path, but my results mirror yours.

On w32 systems like Cywgin, the emulated forks are very expensive.

Cheers,
Ralf