Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [ANALYSED] kernel object compilation failure unnoticed ?

At Fri, 5 Mar 2010 11:01:35 -0600, Eric Haszlakiewicz 
<> wrote:
Subject: Re: [ANALYSED] kernel object compilation failure unnoticed ?
> On Fri, Mar 05, 2010 at 05:33:33PM +0100, Joerg Sonnenberger wrote:
> > On Fri, Mar 05, 2010 at 04:26:55PM +0000, David Holland wrote:
> > > RECIPES.
> > 
> > ...or prefix them with set -e.
> Perhaps it would be better to cause make to always run /bin/sh with -e?
> (Or, for compatibility, only when a Makefile has some particular variable set)
> I could have sworn it did that already, but maybe I'm thinking of something
> other than bmake.

Indeed I believe other versions of "make" do use "sh -e" (when using
"sh", that is, as it isn't always used).

Of course if "make -i" is used, then "sh" should not be passed "-e".

But then there was this discussion:

So, NetBSD's did once too.

See also FreeBSD PR # 66357 and the related discussion on their lists.

FYI, apparently GNU Make does not use "sh -e" either.

On the other hand David is 100% correct.  Explicit tests for error codes
in Makefile rules, and appropriate handling (eg. with "exit 1") is
always the safest and most understandable and maintainable way to do

The only problem I've had with both the elimination of "sh -e" and other
trickery make uses to avoid using "sh" when possible is that this is all
very confusing.  It's hard sometimes even for an expert to understand
the difference between a "complex shell" command and a simple one and to
know intuitively when make will see a non-zero exit code from the rule
and when it will not.  To eliminate all possibility of surprises it
seems to me that the same result should happen regardless of whether
make executes a multi-line script one line at a time or all at once
through a single shell invocation:

        all: all-1 all-2

                true;   \
                false;  \
                true;   \
                echo "you should not see this! (but you will)"

                echo "you should not see this either!"

Conceptually this is the same as if all rules were always passed
wholesale to "sh" as if they were stand-alone scripts, complete with all
the newlines so that insertion of semicolon separators would not be

Indeed a naive user might expect "make" to do the same for both these
rules, as from a shell script perspective they are identical:

                true; false; true


The whole idea of direct exec() of single-line rules and multiple direct
exec()s of "simple" multi-line rules, all just to save a "sh" exec,
seems a little bogus these days, even for huge projects.  We already
waste orders of magnitude more cycles on extremely over-bloated (obese)
compilers and their redundant "lint"-like processing and nattering.

It's also too bad that "sh -e" is perhaps too blunt a tool to use for
this, though the rare examples I've seen of its failure usually result
from extreme complexity and perhaps unnecessary fragility.

FYI, one example of how confusing it can be to know when "sh" is used
and when it is not, consider that NetBSD's "make" does not seem to know
that "~" is a special shell character.  Try the following Makefile with
both NetBSD make and GNU Make and compare the output:

                echo HOME=$$HOME
                echo ~
                echo ~/tmp
                true && echo ~
                true && echo ~/tmp

You'll see that GNU Make either knows that "~" is a shell special
character, or it always uses "sh" to execute every shell rule; while
NetBSD's make doesn't seem to see the tildes on the second and third
lines and so they come out un-expanded.

                                                Greg A. Woods
                                                Planix, Inc.

<>       +1 416 218 0099

Attachment: pgpXcdCL3ysiG.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index