On Wed, 2010-07-28 at 07:31 -0600, Eric Blake wrote:
> It's not obvious from this announcement (and I haven't been following
> the make lists) whether you are aware: The POSIX 2008 wording has a bug.
> The intent of the Austin Group is that -e must NOT be provided if some
> other mechanism ignores errors for a particular shell invocation (such
> as starting a command with - or invoking 'make -i'):
> http://austingroupbugs.net/view.php?id=257
Gak. No, I wasn't aware of that. I'll sign up for an account there.
However, is this really how other versions of make do things? That
seems just... insane and ridiculous to me.
If your makefile is written to expect that it's invoked with -e, then
allowing the user to turn that off simply by passing -i on the make
command line seems incredibly dangerous!
Suppose you have a makefile like this:
PREFIX = /foo
clean: ; [ "$(PREFIX)" != "" ]; rm -rf $(PREFIX)/*
You are relying on the behavior of -e to cause the rule to exit when the
condition is not met, so that you don't wipe out your entire root
partition.
Now someone comes along and runs "make -i", and voila! Instant
devastation.
Yes, of course this is a contrived example but it's not hard to imagine
perfectly legitimate situations where this would be bad. In the new
POSIX model where -e is expected, you have to anticipate that makefile
recipes will be written to make use of that fact (otherwise why bother?)
and simply turning off that flag on the command line seems really
horrible.
I can see it could be useful when starting a command with "-"; in that
case the person actually writing the command made a conscious decision
that they wanted to disable -e when they wrote the recipe.
It's bad enough that the standard reversed it's previous, very clear
language in such a way that every implementation which has previously
been conforming to the standard was no longer conforming, but to require
such (IMO) non-sensical features is a disservice. Is the only function
of the standard to codify existing behavior (of some subset of
implementations--no one seems to have been concerned about the existing
behavior of GNU make, arguably the most widely used make implementation)
without any judgement as to whether it is a good idea?
--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@gnu.org> 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
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
