[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-standards
Subject: Re: 'make clean' vs /bin/sh, posix behavior?
From: Garance A Drosihn <drosih () rpi ! edu>
Date: 2001-06-19 21:34:30
[Download RAW message or body]
[
I am sending this to freebsd-standards with a blind-CC to
freebsd-hackers. I wanted to see if this trick would get the
first message to show up on both lists, but avoid the problem
where the ongoing discussion is cross-posted to multiple lists.
]
Back on May 28th, in the freebsd-hackers thread about:
Re: 'make clean' vs automake vs /bin/sh, which to fix?
I (garance) wrote:
>It seems to me that if 'make' is executing a single command
>line which is made up of multiple unix commands, it should
>only care about the FINAL command status, and not the status
>of each of the interim commands. That is just my gut feeling
>though, I can't tell if the documentation really spells out
>what is to happen in this case.
>
>So, we could fix [my described problem] by:
> 1) changing /bin/sh
> 2) changing make not to call /bin/sh with -e
> 3) [...dumb option...]
>
>Me, I'm inclined to go with the some fix to the evaltree routine
>in /bin/sh, [...fixing bug in '-e'. This is already done...]
>
>While I do wonder about 'make' calling '/bin/sh -e', I am
>less comfortable with committing that change myself, as
>there probably are makefiles which do assume the e-style
>behavior when handling multiple commands in a command-line.
>Perhaps we should update the documentation for 'make' to
>explicitly mention how 'make' handles such command-lines.
A pretty similar topic came up on the 'subversion' mailing list,
and At 4:20 PM -0400 6/19/01, Paul D. Smith wrote:
> + 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.
> [in the example discussed on the subversion mailing list]
> +
> + 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 <psmith@gnu.org> Find some GNU make tips at:
> http://www.gnu.org http://www.paulandlesley.org/gmake/
So, I'm wondering if that's what POSIX really wants as the standard
behavior. I don't THINK we want to change the behavior of our own
'make', but I do wonder if we should at least document this detail
in the man page for 'make'.
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic