[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: Thu, 29 Sep 2011 12:28:26 +0700

On 29 Sep 2011, at 00:58, Paul Eggert wrote:
> On 09/28/11 09:45, Bruno Haible wrote:
>> If the package's configure.ac already invokes AC_PROG_CC_STDC,
>> early on (i.e. usually right after AC_PROG_CC), then gnulib's
>> will be a no-op.
> Ah, sorry, then 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.

Autoconf makes it easy to enforce and document these kinds of order
dependencies though:


I'm happy to create a proper patch to this effect if the gnulib
folks would prefer.

>  And nobody uses
> the corresponding C99 or C89 macros, as far as I know (if they
> do, they should switch to AC_PROG_CC_STDC anyway :-).

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.

> Autoconf should be fixed too, of course, but that's a longer-term
> project.

The patch is very straight forward:


And possibly similar for AC_PROG_CC_STDC if that is not multi-call
safe afterwards.

I'm happy to create and test  proper git patch with a ChangeLog if
the autoconf folks would prefer.

Gary V. Vaughan (gary AT gnu DOT org)

reply via email to

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