On 09/30/11 08:57, Andrew W. Nosenko wrote:
> Assuming that AC_PROG_CC_C99 is not available (e.g. doesn't exists and
> never existed), and only one macro is AC_PROG_CC_STDC, how I should to
> express that "c99 is required"? Or "c99 or better is required"?
Right now, you can't. That would need to
On Fri, Sep 30, 2011 at 17:02, Paul Eggert wrote:
> On 09/30/11 02:06, Bruno Haible wrote:
>> -- Macro: AC_PROG_CC_STDC
>> If the C compiler cannot compile ISO Standard C (currently C99),
>> ...
>>
>> sounds like this macro will then be modified to enable C1X instead of C99.
>
> Yes.
>
[Re-adding bug-autoconf]
Hi Bruno,
On 30 Sep 2011, at 16:56, Bruno Haible wrote:
> Gary V. Vaughan wrote:
>> But why emit a warning when
>> we can just fix-up the definition on the fly? ...
>> This changeset fixes AC_PROG_CC_C99
>> (and effectively AC_PROG_CC_STDC) whether it is called before or
On 09/30/11 02:06, Bruno Haible wrote:
> -- Macro: AC_PROG_CC_STDC
> If the C compiler cannot compile ISO Standard C (currently C99),
> ...
>
> sounds like this macro will then be modified to enable C1X instead of C99.
Yes.
> But I expect that many packages will not need this.
It sho
Gary V. Vaughan wrote:
> I don't think many users will find this before they are already bitten.
>
> IMHO, the two main places in gnulib that people see instructions are in
> the output of gnulib-tool itself:
>
> ...
> Don't forget to
> ...
> - invoke gl_EARLY in ./configure.ac, right aft
Gary V. Vaughan wrote:
> But why emit a warning when
> we can just fix-up the definition on the fly? ...
> 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!
> ...
> +[AC_PROVID
Paul Eggert wrote:
> I don't think the autoconf patch would be that easy, as one would
> need to handle a mixture of AC_PROG_CC_C99, AC_PROG_CC_C89, and
> AC_PROG_CC_STDC calls. Again, I expect the only thing that's
> saved us is that people just use AC_PROG_CC_STDC. Hmm, maybe
> Autoconf should
Gary V. Vaughan wrote:
> > Do you have some specific modules in mind which could
> > be simplified by use of AC_REQUIRE([AC_PROG_CC_STDC])?
>
> I hadn't even considered the possibility of simplifying any specific macros,
> I was thinking entirely about whether whole modules could be skipped by
> p
Hi Bruno,
On 29 Sep 2011, at 16:14, Bruno Haible wrote:
>> 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 modul
Hi Bruno,
On 29 Sep 2011, at 16:14, Bruno Haible wrote:
> 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
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
On 09/29/11 02:14, Bruno Haible wrote:
> 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
> n
[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
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
>> AC_REQUIRE([AC_PROG_CC_STDC])
>> will be a no-op.
>
> Ah, sorry, then we're f
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
> AC_REQUIRE([AC_PROG_CC_STDC])
> will be a no-op.
Ah, sorry, then we're fine as-is, since it's normal practice
to put the AC_PR
Paul Eggert wrote:
> The simplest fix would be something like the patch at the end of
> this message.
> diff --git a/modules/stdarg b/modules/stdarg
>
> index 84d3e7b..ab3436e 100644
>
> --- a/modules/stdarg
On 09/28/11 01:52, Gary V. Vaughan wrote:
> Might as well try to fix it right in gnulib though, and maybe in autoconf
>> too if the latest release hasn't made it multi-call safe yet.
The simplest fix would be something like the patch at the end of
this message. This matches common practice anyway
From a private discussion about preventing CFLAGS getting -std=gnu99 twice,
that leads to a bug report for gnulib and maybe autoconf too...
Begin forwarded message:
> From: "Gary V. Vaughan"
> Subject: Re: Getting AC_PROG_CC_C99
> Date: 28 September 2011 12:38:33 GMT+07:00
18 matches
Mail list logo
