bug-gnulib
[Top][All Lists]
Advanced

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

Re: Getting AC_PROG_CC_C99


From: Bruno Haible
Subject: Re: Getting AC_PROG_CC_C99
Date: Thu, 29 Sep 2011 11:14:33 +0200
User-agent: KMail/1.13.6 (Linux/2.6.37.6-0.5-desktop; KDE/4.6.0; x86_64; ; )

[Dropping bug-autoconf from CC]

Gary V. Vaughan wrote:
> > we're fine as-is, since it's normal practice
> > to put the AC_PROG_CC_STDC before gl_EARLY.
> 
> I discovered the multiple --std=gnu99 option problem because no
> one told me that it's normal to to put AC_PROG_CC_STDC before
> gl_EARLY, I just saw the instructions to invoke gl_EARLY as soon
> as possible after AC_PROG_CC, so I did that and inserted gl_EARLY
> immediately following AC_PROG_CC, and before the AC_PROG_CC_STDC
> that came directly after.

OK, let me update the documentation. Patch attached.

> 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?

> 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'm still curious why gnulib doesn't try to put the compiler into
> c99 mode when the client project has chosen some gnulib c99 compliance
> modules?  After all, it might be that with the compiler in c99 mode
> fewer of the gnulib modules are needed to fix up non-compliances than
> when the compiler is in default mode.

This is true. But switching the compiler to a different standards-compliance
mode is a global effect. I was not sure whether it would have some negative
side effects on some platforms.

On the other hand, we do it in module 'stdarg' for 5 years now, and it has
not caused bug reports.

So, yes, that is something we could do to reduce the number of workarounds
we have in gnulib. Do you have some specific modules in mind which could
be simplified by use of AC_REQUIRE([AC_PROG_CC_STDC])?

Bruno


2011-09-29  Bruno Haible  <address@hidden>

        doc: Improve doc about gl_EARLY.
        * doc/gnulib-tool.texi (Initial import): Mention where to place an
        AC_PROG_CC_STDC invocation.
        Reported by Gary V. Vaughan <address@hidden>.

--- doc/gnulib-tool.texi.orig   Thu Sep 29 10:50:25 2011
+++ doc/gnulib-tool.texi        Thu Sep 29 10:47:52 2011
@@ -217,6 +217,17 @@
 ...
 @end example
 
+If you are using @code{AC_PROG_CC_STDC}, the macro @code{gl_EARLY} must
+be called after it, like this:
+
address@hidden
+...
+AC_PROG_CC
+AC_PROG_CC_STDC
+gl_EARLY
+...
address@hidden example
+
 The core part of the gnulib checks are done by the macro
 @code{gl_INIT}.  Place it further down in the file, typically where
 you normally check for header files or functions.  It must come after

--
In memoriam Cheb Hasni <http://en.wikipedia.org/wiki/Cheb_Hasni>



reply via email to

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