> Date: Fri, 23 Aug 2002 14:31:56 +0100 > From: Andrew Suffield <[EMAIL PROTECTED]>
> > Autoconf doesn't assume that the system C compiler supports ANSI > > prototypes. > > Then it should test for that, not assume it is running K&R. That is a bit too strong, as Autoconf-generated scripts work fine with a Standard C compiler (either C89 or C99) as well as with K&R C. Your problem is that you are specifying a C compiler that rejects traditional-style function definitions. Such a compiler will work perfectly well with many projects, but it is not a standard C compiler and it will break Autoconf-generated "configure" scripts in several cases. > I find the "feature" of supporting K&R at the expense of ANSI to be > rather less than useful, especially since almost all the > autoconf-using project nowdays don't support K&R C anyway. There are still some important exceptions, GCC itself being one of them (for bootstrapping reasons), and Autoconf must support them. > Additionally, if running with different CFLAGS is not supported, > there's a different bug: autoconf uses whatever value for $CFLAGS you > had set in the shell. That behavior is documented in the Autoconf manual. > I should be able to set CFLAGS to whatever I want to compile with, Not if you set CFLAGS to a value that breaks the compiler. The only question here is what constitutes "breakage". I'm sympathetic to your problem and I think Autoconf should be fixed to allow overly-pedantic compilers like yours. However, it's not a trivial fix, since we must continue to support K&R C for some time. The biggest problem will be things like AC_TRY_LINK_FUNC; I don't see any easy way to fix that without changing the invoking syntax, and that is not a backward-compatible change.
