autoconf-patches
[Top][All Lists]
Advanced

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

Re: AS_IF optimization


From: Eric Blake
Subject: Re: AS_IF optimization
Date: Fri, 10 Apr 2009 17:00:26 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us> writes:

> 
> This would be a good time to eliminate the term "hairy constructs" 
> which is surely confusing to people for whom english is a second 
> language.

Sure; I'll use 'lengthy' instead of 'hairy'.

> According to Ralf Wildenhues on 4/9/2009 11:56 PM:
> > 
> > Can you hold back on this for a couple of days?  I'm still in the
> > process of going through Automake testsuite results, and might have
> > found a tangent issue.
> 
> Sure.  Perhaps it is a case where it is 'set -e' making a difference?

Speaking of 'set -e' and makefiles, did you realize that POSIX 2008 changed 
things for make?

"The execution line shall then be executed by a shell as if it were passed as 
the argument to the system( ) interface, except that the shell −e option shall 
also be in effect."

Particularly annoying, since POSIX 2008 is inconsistent on how 'set -e' behaves 
in the first place.  This link shows what the Austin group decided on for the 
sanest semantics:

http://www.opengroup.org/austin/mailarchives/ag-review/msg03507.html

So I guess I'd better add this patch to my queue, and wait for Ralf's analysis 
of how automake is faring with things learned in this thread.


From: Eric Blake <address@hidden>
Date: Fri, 10 Apr 2009 10:56:40 -0600
Subject: [PATCH] Mention latest rules about make and set -e.

* doc/autoconf.texi (Failure in Make Rules): Posix is now clear
that make must use set -e.
(Limitations of Builtins) <set>: Clarify more about set -e
behavior.

Signed-off-by: Eric Blake <address@hidden>
---
 ChangeLog         |    6 ++++++
 doc/autoconf.texi |   53 +++++++++++++++++++++++++++++++++++++++--------------
 2 files changed, 45 insertions(+), 14 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 7474749..7208de2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 2009-04-10  Eric Blake  <address@hidden>

+       Mention latest rules about make and set -e.
+       * doc/autoconf.texi (Failure in Make Rules): Posix is now clear
+       that make must use set -e.
+       (Limitations of Builtins) <set>: Clarify more about set -e
+       behavior.
+
        Improve documentation about if exit status.
        * doc/autoconf.texi (Limitations of Builtins) <if>: Mention that
        exit status bugs don't affect modern targets.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 25017bb..82c2317 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -15971,16 +15971,42 @@ Limitations of Builtins
 set -ex
 @end example

address@hidden @command{set -e}
+The option @option{-e} has historically been underspecified, with enough
+ambiguities to cause numerous differences across various shell
+implementations.  Perhaps the best reference is
address@hidden://www.opengroup.org/@/austin/@/mailarchives/@/ag-
review/@/msg03507.html,
+this link}, recommending a change to Posix 2008 to match @command{ksh88}
+behavior.  Note that mixing @code{set -e} and shell functions is asking
+for surprises:
+
address@hidden
+set -e
+doit()
address@hidden
+  rm file
+  echo one
address@hidden
+doit || echo two
address@hidden example
+
address@hidden
+According to the recommendation, @samp{one} should always be output
+regardless of whether the @command{rm} failed, because it occurs within
+the body of the shell function @samp{doit} invoked on the left side of
address@hidden||}, where the effects of @samp{set -e} are not enforced.
+Likewise, @samp{two} should never be printed, since the failure of
address@hidden does not abort the function, such that the status of
address@hidden is 0.
+
 The @acronym{BSD} shell has had several problems with the @option{-e}
-option, partly because @acronym{BSD} @command{make} traditionally used
address@hidden even though this was incompatible with Posix
-(@pxref{Failure in Make Rules}).  Older versions of the @acronym{BSD}
+option.  Older versions of the @acronym{BSD}
 shell (circa 1990) mishandled @samp{&&}, @samp{||}, @samp{if}, and
 @samp{case} when @option{-e} was in effect, causing the shell to exit
 unexpectedly in some cases.  This was particularly a problem with
 makefiles, and led to circumlocutions like @samp{sh -c 'test -f file ||
 touch file'}, where the seemingly-unnecessary @samp{sh -c '@dots{}'}
-wrapper works around the bug.
+wrapper works around the bug (@pxref{Failure in Make Rules}).

 Even relatively-recent versions of the @acronym{BSD} shell (e.g.,
 address@hidden 3.4) wrongly exit with @option{-e} if a command within
@@ -17500,16 +17526,15 @@ $< in Ordinary Make Rules
 @node Failure in Make Rules
 @section Failure in Make Rules

-Since 1992 Posix has required that @command{make} must invoke
-each command with the equivalent of a @samp{sh -c} subshell.  However,
-many @command{make} implementations, including @acronym{BSD} make through 2004,
-use @samp{sh -e -c} instead, and the @option{-e} option causes the
-subshell to exit immediately if a subsidiary simple-command fails.  For
-example, the command @samp{touch T; rm -f U} always attempts to
-remove @file{U} with Posix make, but incompatible
address@hidden implementations skip the @command{rm} if the
address@hidden fails.  One way to work around this is to reword the
-affected simple-commands so that they always succeed, e.g., @samp{touch
+Posix 2008 requires that @command{make} must invoke each command with
+the equivalent of a @samp{sh -e -c} subshell, which causes the
+subshell to exit immediately if a subsidiary simple-command fails,
+although not all @command{make} implementations have historically
+followed this rule.  For
+example, the command @samp{touch T; rm -f U} may attempt to
+remove @file{U} even if the @command{touch} fails, although this is not
+permitted with Posix make.  One way to work around failures in simple
+commands is to reword them so that they always succeed, e.g., @samp{touch
 T || :; rm -f U}.
 However, even this approach can run into common bugs in @acronym{BSD}
 implementations of the @option{-e} option of @command{sh} and
-- 
1.6.1.2








reply via email to

[Prev in Thread] Current Thread [Next in Thread]