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 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: AC_DEFUN([gl_EARLY], [ ... AC_BEFORE([$0], [AC_PROG_CC_C99]) ... ]) 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: AC_DEFUN([AC_PROG_CC_C99], [ ... m4_define([AC_PROG_CC_C99]) ]) 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. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
