[Top][All Lists]

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

Re: Getting AC_PROG_CC_C99

From: Gary V. Vaughan
Subject: Re: Getting AC_PROG_CC_C99
Date: Fri, 30 Sep 2011 10:19:38 +0700

On 29 Sep 2011, at 16:14, Bruno Haible wrote:
> Gary V. Vaughan wrote:
> > Autoconf makes it easy to enforce and document these kinds of order
> > dependencies though:
> > 
> > AC_DEFUN([gl_EARLY], [
> > ...
> > AC_BEFORE([$0], [AC_PROG_CC_C99])
> > ...
> > ])
> Rather, the order should be that AC_PROG_CC_STDC and AC_PROG_CC_C99
> must come before (or inside) gl_EARLY. I think the right way to
> implement this is not AC_BEFORE, but rather to have gl_EARLY add
> some code to the end of m4_defn([AC_PROG_CC_STDC]) and
> m4_defn([AC_PROG_CC_C99]) that will emit a warning, right?

Quite right, I had my logic reversed.  But why emit a warning when
we can just fix-up the definition on the fly?  There's no need to
do anything to AC_PROG_CC_STDC I think, since it doesn't have the
multiple append problem itself, only by virtue of causing another
expansion of AC_PROG_CC_C99.  This changeset fixes AC_PROG_CC_C99
(and effectively AC_PROG_CC_STDC) whether it is called before or
after gl_EARLY, directly or by AC_PROG_CC_STDC, or even not at all!

By putting the fix in gl_EARLY rather than autoconf itself, there's
still the possibility of getting multiple expansions with something


But that seems pathological to me in any case, so I haven't tried to
address that.

> > I'm happy to create a proper patch to this effect if the gnulib
> > folks would prefer.
> Yes, please, that would be nice if you can find out how the modified
> gl_EARLY definition should look like. Then we can modify gnulib-tool
> to incorporate this change.

I didn't look at AC_PROG_CC_C89, though I suppose it's likely to need
a similar fix if it decides to add flags to CC on every expansion like
its cousin AC_PROG_CC_C99...


* m4/gnulib-common (gl_PROG_CC_C99_ONCE): New macro to automatically
neuter AC_PROG_CC_C99 after first invocation.
* gnulib-tool (func_import): Invoke gl_PROG_CC_C99_ONCE in gl_EARLY.
 ChangeLog           |    7 +++++++
 gnulib-tool         |    1 +
 m4/gnulib-common.m4 |   10 ++++++++++
 3 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 0a63ba0..6cbbf5d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2011-09-30  Gary V. Vaughan  <address@hidden>
+       stdarg: don't expand AC_PROG_CC_C99 multiple times.
+       * m4/gnulib-common (gl_PROG_CC_C99_ONCE): New macro to automatically
+       neuter AC_PROG_CC_C99 after first invocation.
+       * gnulib-tool (func_import): Invoke gl_PROG_CC_C99_ONCE in gl_EARLY.
 2011-09-29  Bruno Haible  <address@hidden>
        doc: Improve doc about gl_EARLY.
diff --git a/gnulib-tool b/gnulib-tool
index 36135e6..9b65ce0 100755
--- a/gnulib-tool
+++ b/gnulib-tool
@@ -5139,6 +5139,7 @@ s,//*$,/,'
     echo "  m4_pattern_allow([^gl_LIBOBJS\$])dnl a variable"
     echo "  m4_pattern_allow([^gl_LTLIBOBJS\$])dnl a variable"
     echo "  AC_REQUIRE([gl_PROG_AR_RANLIB])"
+    echo "  gl_PROG_CC_C99_ONCE"
     if test -n "$uses_subdirs"; then
       echo "  AC_REQUIRE([AM_PROG_CC_C_O])"
diff --git a/m4/gnulib-common.m4 b/m4/gnulib-common.m4
index 8fc448f..24bc1c1 100644
--- a/m4/gnulib-common.m4
+++ b/m4/gnulib-common.m4
@@ -211,6 +211,16 @@ m4_ifndef([AS_VAR_IF],
 [AS_IF([test x"AS_VAR_GET([$1])" = x""$2], [$3], [$4])])])
+# gl_PROG_CC_C99
+# AC_PROG_CC_C99 potentially appends '-std=gnu99' (or similar) to CC every
+# time it is expanded, so make sure it has an empty definition before any
+# second expansion.
+        [AC_DEFUN([AC_PROG_CC_C99])],
+    m4_defn([AC_PROG_CC_C99])[AC_DEFUN([AC_PROG_CC_C99])])])])
 # Determines the values for AR, ARFLAGS, RANLIB that fit with the compiler.
 # The user can set the variables AR, ARFLAGS, RANLIB if he wants to override

reply via email to

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