Re: .ONESHELL enhancement?

On Sun, 2009-10-04 at 08:26 -0400, David Boyce wrote:
> On Sun, Oct 4, 2009 at 4:50 AM, Ralf Wildenhues <[email protected]> wrote:
> > Well, part of the practical issue will be that users of Automake will
> > likely want to put .ONESHELL in their Makefile.am files so it applies to
> > their rules; but then it will apply to those generated by automake as
> > well.  So then Automake needs to either document that this is forbidden,
> > or adjust its rules.  The simplest way to do it of course causes more
> > overhead also for those not using .ONESHELL.
> 
> 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.

Boris Kolpackov <[email protected]> writes:
> I don't like the idea that .ONESHELL will realistically only work 
> for specially-crafted makefiles (and that's where, I feel, it is
> going). This way it becomes a feature for a "special interest" group.
> I would much prefer it being smart enough to be able to work with a 
> wide range of existing build systems. Or, at least, issue warnings
> for incompatible constructs so that a build system can be fixed.

The problem, as Matt pointed out, is that I don't think this is
feasible.  I definitely do NOT want to add a generic shell parser into
GNU make, and without that I just can't see any even remotely reasonable
way to issue any sort of warning (except as documentation in the GNU
make manual, of course).  Maybe I'm not clear on what you had in mind.

Doing something like adding () to every line, to me, defeats the main
advantage of .ONESHELL; that you can write your command line as a
"normal" shell script, except prefixed with TAB, and it works; that is
variable assignments are preserved, etc.  And as has been mentioned, you
could set SHELL to something completely different (Perl, Python, Ruby,
etc.)  Also I don't know that this will be appropriate to David's
requirement, because again it invokes commands in sub-shells (but maybe
that's OK in this case; David will have to judge that).

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), or else we want
it to actually add a new capability to GNU make, in which case it should
simply pass the entire recipe to the shell without modification (except
with the initial TAB removed as is currently done).

Matt McCutchen <[email protected]> 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:
> 
> $ time bash -c 'for i in {1..1000}; do (true); done'
> 
> real    0m0.878s
> user    0m0.190s
> sys     0m0.813s
> 
> $ time bash -c 'for i in {1..1000}; do bash -c true; done'
> 
> real    0m3.595s
> user    0m1.454s
> sys     0m2.132s

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


But here's the thing: from this it seems like 1000 extra execs adds less
than 2 seconds to the build.  I just can't believe that this kind of
minimal performance improvement justifies a feature like .ONESHELL.  To
me this makes a stronger argument for adding .ONESHELL because it adds
new capabilities (along with appropriate warnings in the manual), and
weakens the argument for adding .ONESHELL as a 100% compatible,
performance-only improvement.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email protected]>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist