[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: .ONESHELL enhancement?
From: |
Ralf Wildenhues |
Subject: |
Re: .ONESHELL enhancement? |
Date: |
Mon, 5 Oct 2009 06:23:35 +0200 |
User-agent: |
Mutt/1.5.20 (2009-08-09) |
* 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
- Re: .ONESHELL enhancement?, Ralf Wildenhues, 2009/10/03
- Re: .ONESHELL enhancement?, David Boyce, 2009/10/03
- Re: .ONESHELL enhancement?, Boris Kolpackov, 2009/10/04
- Re: .ONESHELL enhancement?, Ralf Wildenhues, 2009/10/04
- Re: .ONESHELL enhancement?, David Boyce, 2009/10/04
- Re: .ONESHELL enhancement?, Paul Smith, 2009/10/04
- Re: .ONESHELL enhancement?,
Ralf Wildenhues <=
- Re: .ONESHELL enhancement?, Matt McCutchen, 2009/10/05
- Re: .ONESHELL enhancement?, Ralf Wildenhues, 2009/10/05
- Re: .ONESHELL enhancement?, Matt McCutchen, 2009/10/05
- Re: .ONESHELL enhancement?, Ralf Wildenhues, 2009/10/07
Re: .ONESHELL enhancement?, Matt McCutchen, 2009/10/04