On Sunday 05 April 2009 20:46:03 Eric Blake wrote:
According to Mike Frysinger on 4/5/2009 4:10 PM:
AC_TRY_COMPILE() is invoked with an empty 4th argument: []. i think
[ sp_expire_available=yes ], []
)
That's not an empty fourth argument. Remember, trailing space IS
simple example:
$ cat configure.ac
AC_INIT
AS_IF([:], [
: some random user stuff
],[
AC_PROG_LEX
AC_DECL_YYTEXT
])
AC_OUTPUT
$ autoconf --version
autoconf (GNU Autoconf) 2.64
$ autoconf ./configure -q
./configure: line 2676: syntax error near unexpected token `fi'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 4/9/2009 10:27 PM:
I'm also leaning towards omitting the else if $1 is provably blank,
otherwise providing the : in case non-blank $1 ultimately expands to a
blank (unless someone finds a shell where 'if false ; then :;
Eric Blake ebb9 at byu.net writes:
Sorry for committing before the testsuite completed. It turns out that
this introduced a regression in 'make check TESTSUITEFLAGS=-k
AC_RUN_IFELSE', due to the following:
$ if false; then :; else echo $?; fi
1
In the process of trying to work around
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Mike Frysinger on 4/14/2009 4:27 PM:
$ if false; then :; else echo $?; fi
1
But adding the : after the else, we have effectively made it impossible
for the user to grab $? after the if condition, so I'll have to rethink
this patch.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Mike Frysinger on 4/14/2009 8:11 PM:
well, is there any real need to preserve the exit value of the if statement ?
in other words, past implementations of autoconf didnt preserve it and it
isnt
like anyone complained. the old
On Tuesday 14 April 2009 09:41:33 Eric Blake wrote:
According to Eric Blake on 4/9/2009 10:27 PM:
I'm also leaning towards omitting the else if $1 is provably blank,
otherwise providing the : in case non-blank $1 ultimately expands to a
blank (unless someone finds a shell where 'if false ;
On Tuesday 14 April 2009 21:09:47 Eric Blake wrote:
According to Mike Frysinger on 4/14/2009 4:27 PM:
$ if false; then :; else echo $?; fi
1
But adding the : after the else, we have effectively made it impossible
for the user to grab $? after the if condition, so I'll have to rethink
On Friday 10 April 2009 00:27:24 Eric Blake wrote:
According to Eric Blake on 4/6/2009 8:25 PM:
According to Mike Frysinger on 4/6/2009 3:43 PM:
I'm also leaning towards omitting the else if $1 is provably blank,
otherwise providing the : in case non-blank $1 ultimately expands to a
blank
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding autoconf-patches, replies can drop autoconf]
According to Eric Blake on 4/6/2009 8:25 PM:
According to Mike Frysinger on 4/6/2009 3:43 PM:
I'm also leaning towards omitting the else if $1 is provably blank,
otherwise providing the : in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Mike Frysinger on 4/9/2009 10:51 PM:
this looks good to me (but didnt actually test), thanks !
perhaps also update the documentation of m4_normalize and m4_strip to refer
to
m4_blank/m4_nblank ?
Good idea. I'm adding this to the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding autoconf-patches, replies can drop autoconf]
According to Eric Blake on 4/6/2009 8:25 PM:
According to Mike Frysinger on 4/6/2009 3:43 PM:
I'm also leaning towards omitting the else if $1 is provably blank,
otherwise providing the : in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Andreas Schwab on 4/7/2009 3:47 AM:
From the autoconf manual:
There are shells that do not reset the exit status from an `if':
$ if (exit 42); then true; fi; echo $?
42
whereas a proper shell should
Eric Blake e...@byu.net writes:
I'm also leaning towards omitting the else if $1 is provably blank,
otherwise providing the : in case non-blank $1 ultimately expands to a
blank (unless someone finds a shell where 'if false ; then :; fi; echo $?'
fails to output 0).
From the autoconf manual:
Eric Blake e...@byu.net writes:
According to Andreas Schwab on 4/7/2009 3:47 AM:
From the autoconf manual:
There are shells that do not reset the exit status from an `if':
$ if (exit 42); then true; fi; echo $?
42
whereas a proper shell should have printed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Mike Frysinger on 4/5/2009 7:19 PM:
i'm not an expert by any means with internal autoconf/m4. if there's a m4
helper function to test whether an argument contains something other than
whitespace, then the change to m4sh.m4:_AS_IF is
On Monday 06 April 2009 08:59:32 Eric Blake wrote:
According to Mike Frysinger on 4/5/2009 7:19 PM:
i'm not an expert by any means with internal autoconf/m4. if there's a
m4 helper function to test whether an argument contains something other
than whitespace, then the change to
Hello Mike, Eric,
* Mike Frysinger wrote on Mon, Apr 06, 2009 at 03:16:53PM CEST:
--- a/lib/m4sugar/m4sh.m4
+++ b/lib/m4sugar/m4sh.m4
@@ -607,7 +607,7 @@ m4_define([_AS_IF],
])
m4_define([_AS_IF_ELSE],
[m4_ifvaln([$1],
-[else
+[else :
$1])])
m4_defun([AS_IF],
I like this one,
On Monday 06 April 2009 14:09:29 Ralf Wildenhues wrote:
Hello Mike, Eric,
* Mike Frysinger wrote on Mon, Apr 06, 2009 at 03:16:53PM CEST:
--- a/lib/m4sugar/m4sh.m4
+++ b/lib/m4sugar/m4sh.m4
@@ -607,7 +607,7 @@ m4_define([_AS_IF],
])
m4_define([_AS_IF_ELSE],
[m4_ifvaln([$1],
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Mike Frysinger on 4/6/2009 3:43 PM:
m4_define([_AS_IF_ELSE],
[m4_ifvaln([$1],
-[else
+[else :
$1])])
m4_defun([AS_IF],
I like this one, for simplicity and obvious correctness alone, but will
defer to Eric for the final
* Eric Blake wrote on Tue, Apr 07, 2009 at 04:25:12AM CEST:
I'm also leaning towards omitting the else if $1 is provably blank,
OK with me.
otherwise providing the : in case non-blank $1 ultimately expands to a
blank (unless someone finds a shell where 'if false ; then :; fi; echo $?'
fails
* Ralf Wildenhues wrote on Tue, Apr 07, 2009 at 07:38:10AM CEST:
But that isn't what you need here. There are situations in which you
cannot prove whether $1 is blank or not. In that case, we should add
both the :\n as well as $1.
Actually, $1 can just expand to `#\n' (that is, comment
On Monday 06 April 2009 22:25:12 Eric Blake wrote:
Now for a question - right now, m4_default([$1], [$2]) is a nice shorthand
for m4_ifval([$1], [$1], [$2]); is there any reason to create a shorthand
for m4_ifnblank([$1], [$1], [$2]) that likewise only needs two arguments?
And if so, what to
after upgrading from 2.63 to 2.63b, i noticed some code configure.ac files
(like in openssh) results in invalid shell code. this is because
AC_TRY_COMPILE() is invoked with an empty 4th argument: []. i think
specifically, this:
AC_TRY_COMPILE(
[
#include sys/types.h
#include
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Mike Frysinger on 4/5/2009 4:10 PM:
AC_TRY_COMPILE() is invoked with an empty 4th argument: []. i think
[ sp_expire_available=yes ], []
)
That's not an empty fourth argument. Remember, trailing space IS
significant,
On Sunday 05 April 2009 20:46:03 Eric Blake wrote:
According to Mike Frysinger on 4/5/2009 4:10 PM:
AC_TRY_COMPILE() is invoked with an empty 4th argument: []. i think
[ sp_expire_available=yes ], []
)
That's not an empty fourth argument. Remember, trailing space IS
On Sunday 05 April 2009 21:01:29 Mike Frysinger wrote:
On Sunday 05 April 2009 20:46:03 Eric Blake wrote:
That said, autoconf could probably be taught that, for some macros, an
argument of all whitespace is morally equivalent to an empty argument.
Patches welcome.
i'm not an expert by any
27 matches
Mail list logo
