- the new AC_REQUIRE warnings may not be easy to solve in general.
Consider the following situation: you require two macros, both from
different third parties (a third and a fourth party?). One requires
a common macro, say AC_PROG_CC, another expands it.
I think that would be a bug in the
Found this while running the bison testsuite after upgrading to 2.63b:
$ make check TESTSUITEFLAGS=56-57
...
## -- ##
## GNU Bison 2.4.284-3583 test suite. ##
## -- ##
Output file names.
56: Output file name: )
Hi Eric,
* Eric Blake wrote on Mon, Apr 06, 2009 at 07:14:36PM CEST:
Ralf, do you think we should also add a 'parallel syntax check' test?
Yes, definitely. And thanks for this patch and the testsuite size
reduction!
Cheers,
Ralf
Eric Blake ebb9 at byu.net writes:
One fix could be to just ignore those two variables in AT_CHECK_ENV.
Good idea. I'm pushing this. I'm also looking at a way to make
autoconf's testsuite much smaller, by factoring AT_CHECK_ENV and
AC_SAVE_STATE into reused contents rather than
Hello Eric,
I would like to fix the remaining glitch in
http://article.gmane.org/gmane.comp.sysutils.automake.patches/3528
and one method I've been able to come up with was to rely on
_AC_SUBST_VARS.
This variable is undocumented, but has been used much before 2.62
(which is the Autoconf version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding automake-patches]
According to Ralf Wildenhues on 4/6/2009 2:48 PM:
This variable is undocumented, but has been used much before 2.62
(which is the Autoconf version current Automake requires). Would
it be ok to rely on this undocumented
* Eric Blake wrote on Tue, Apr 07, 2009 at 04:41:58AM CEST:
According to Ralf Wildenhues on 4/6/2009 2:48 PM:
This variable is undocumented, but has been used much before 2.62
(which is the Autoconf version current Automake requires). Would
it be ok to rely on this undocumented variable,
-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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 4/6/2009 4:00 AM:
If the
latter, then no, I don't think we should document that. We should just
document that config.status works only on text files, i.e., the line
length is limited to LINE_MAX
Saying only text
Ralf Wildenhues wrote:
Are you complaining that the limitation of 'awk' is not documented, or
that the limitation of 'config.status' is not documented?
Actually, both. The limitation of 'awk' can be documented in section
Limitations of Usual Tools, and the limitation about config.status
should
17 matches
Mail list logo
