Re: .ONESHELL enhancement?

[Matt McCutchen]

On Mon, 2009-10-05 at 06:23 +0200, Ralf Wildenhues wrote:
> On w32 systems like Cywgin, the emulated forks are very expensive.

True.  Using a single shell with each line in parentheses doesn't
constitute an optimization on Cygwin.  But I believe we decided not to
attempt this kind of retrofitting of existing build systems in make
anyway.

> * Paul Smith wrote on Sun, Oct 04, 2009 at 07:36:15PM CEST:
> > 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.

Yes.  I suppose this is the real problem: if automake generates a
multiline command script that relies on shell state not being preserved,
it would have to add parentheses to work in .ONESHELL mode, but that
would be slow on Cygwin.  IMO, the solution is for automake to avoid
generating such scripts by splitting the lines into separate targets.
Code generated by automake is already subject to many portability
constraints; what's one more?  :D

-- 
Matt