You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Garance A Drosihn <dr...@rpi.edu> on 2001/06/19 20:08:25 UTC

Re: BSD (+/bin/sh) vs. GNU make -- `make check'

At 10:14 PM -0500 6/17/01, Ben Collins-Sussman wrote:
>This bit of code from Makefile.in is part of the 'check' target:
>
>	    echo "START: $$progbase" >> $$logfile ; \
>	    (cd $$progdir && ./$$progbase $(abs_srcdir)) >> $$logfile ; \
>	    if test $$? -eq 0; then \
>		echo "SUCCESS" ; \
>	    else \
>		failed=yes; \
>		echo "FAILED" ; \
>		echo "--- at least one sub-test FAILED, check tests.log." ; \
>	    fi; \
>	    echo "END: $$progbase" >> $$logfile ; \
>
>
>The problem I'm noticing on my FreeBSD systems: if one of the test
>programs returns non-zero, we never see the "FAILED" message in the
>else clause.  Instead, the BSD version of 'make' simply bombs out on
>the spot and prints "*** Error code N".

I was just in this area on freebsd, fixing a similar problem.  Some
automake-generated make targets would fail with '*** Error code n'
when they should not have.  I did fix that issue in freebsd-current,
and will be copying the fix to freebsd-stable sometime soon.  That
doesn't fix things for the above, though.

>I'd like to not be dependent on the fact that GNU make is more
>tolerant than others.  Is there a way to change the script above
>so that older 'make's won't instantly bomb on error?

Note that in freebsd-land (at least), this is not an issue with
'make', it is an issue with '/bin/sh'.  As far as 'make' is
concerned, that whole mess above is a single command which it
executes using '/bin/sh -e' processing.  It is the shell that
is deciding to error-out.

There is a trick to how the shell handles error-check processing.
It wants to know you're checking the status of the just-finished
command before it starts to execute the next command.  (at least,
I think that is it's intent).  So, the command-which-might-fail
must be IN the 'if', or it must be tested by using '||' or '&&'
for the command-separator.

so, you tend to do things like:
    cmdok=NO ; cd $$progdir && ./$$prog >> $$log && cmdok=YES

The cmdok=YES part will only be executed if both the 'cd' and '$prog'
worked.  You then check the value of cmdok in the 'if' statement.

-- 
Garance Alistair Drosehn            =   gad@eclipse.acs.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: BSD (+/bin/sh) vs. GNU make -- `make check'

Posted by "Paul D. Smith" <pa...@nortelnetworks.com>.
Just a note on this subject (I just joined the list so hopefully this
hasn't already been mentioned).

The difference I believe you're alluding to is whether make invokes
/bin/sh with the -e option by default or not.

Many (most) versions of make do actually invoke with the -e option,
always.  However, the POSIX.2 definition of make is very clear on this
point, that make should invoke "/bin/sh -c ...".

GNU make follows the POSIX standard in this, rather than tradition.
That's why GNU make doesn't fail immediately.

The simple way to ensure that all versions of make behave the same is to
tell the shell explicitly what to do with the e flag; for example if you
want to ignore errors in all versions of make you can use "set +e" to
disable the "e" flag if it's set:

            set +e; \
	    echo "START: $$progbase" >> $$logfile ; \
                ...

I think that's pretty portable.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <ps...@gnu.org>          Find some GNU make tips at:
 http://www.gnu.org                      http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org