Re: Feature request: AC_PROG_CC_* macros for gnu89/gnu99-compliant compiler
On 02/02/2013 05:13 AM, Michał Górny wrote: In order to solve that properly, I would like to request having two new macros in autoconf: AC_PROG_CC_GNU89 and AC_PROG_CC_GNU99, in a similar manner to the AC_PROG_CC_C99 macro. We've been moving in the opposite direction: AC_PROG_CC_STDC, AC_PROG_CC_C89 and AC_PROG_CC_C99 will be marked as obsolescent in the next version of Autoconf. The idea is that AC_PROG_CC should just work, and maintainers shouldn't have to fiddle with all those AC_PROG_CC_whatever macros whenever a new compiler comes out. Can you give an example of a package that has a problem, and symptoms of the problem? That might help us come up with a better solution. For example, what happens if you configure with ./configure CC='clang -std=gnu11'? ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Feature request: AC_PROG_CC_* macros for gnu89/gnu99-compliant compiler
On Sat, 02 Feb 2013 08:36:17 -0800 Paul Eggert egg...@cs.ucla.edu wrote: On 02/02/2013 05:13 AM, Michał Górny wrote: In order to solve that properly, I would like to request having two new macros in autoconf: AC_PROG_CC_GNU89 and AC_PROG_CC_GNU99, in a similar manner to the AC_PROG_CC_C99 macro. We've been moving in the opposite direction: AC_PROG_CC_STDC, AC_PROG_CC_C89 and AC_PROG_CC_C99 will be marked as obsolescent in the next version of Autoconf. The idea is that AC_PROG_CC should just work, and maintainers shouldn't have to fiddle with all those AC_PROG_CC_whatever macros whenever a new compiler comes out. Can you give an example of a package that has a problem, and symptoms of the problem? That might help us come up with a better solution. For example, what happens if you configure with ./configure CC='clang -std=gnu11'? The major issue we've been having is difference in inline semantics between gnu89 and c99. It hit us at least with libgcrypt [1,2], pkg-config [3,4], e2fsprogs [5]. The usual way of fixing it on our side was appending 'std=gnu89' or a similar option. But I believe configure scripts should handle this for us... [1]:https://bugs.gentoo.org/show_bug.cgi?id=420899 [2]:https://bugs.g10code.com/gnupg/issue1406 [3]:https://bugs.gentoo.org/show_bug.cgi?id=297248 [4]:https://bugs.freedesktop.org/show_bug.cgi?id=29313 [5]:https://bugs.gentoo.org/show_bug.cgi?id=297243 -- Best regards, Michał Górny signature.asc Description: PGP signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: Feature request: AC_PROG_CC_* macros for gnu89/gnu99-compliant compiler
On 02/02/2013 09:09 AM, Michał Górny wrote: The major issue we've been having is difference in inline semantics between gnu89 and c99. It hit us at least with libgcrypt [1,2], pkg-config [3,4], e2fsprogs [5]. OK, this is a different matter than what AC_PROG_CC will do. AC_PROG_CC will enable extensions if available. But the inline semantics issue is something where, if I understand things correctly, a package explicitly wants the old GNU inline semantics for 'inline', and doesn't want the C99 semantics for 'inline' that is supported by clang and by newer versions of GCC. That's not an extension: it's a change to the language. One possibility is that Autoconf could add a macro AC_CC_OLD_GNU_INLINE, or something like that, which would cause 'configure' to arrange for the old GNU inline semantics and to fail if this can't be arranged. Is that a macro that you could write? But maybe we don't need to have such a macro. Aren't the packages in question intended to be used with newer compilers? If so, they need to be updated to use C99 semantics for 'inline', since we can't expect every new compiler to support the old GCC 'inline' semantics. And then AC_PROG_CC will already do what we want, since it'll (in the next version of Autoconf, anyway), ask newer GCCs to use the C99-compatible 'inline' semantics. By newer GCCs I mean GCC 4.3 or later, if I'm reading the release notes correctly. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
