Re: AC_PROG_CC_C99

[Noah Misch]

On Wed, Jan 12, 2005 at 08:30:33PM +0000, Roger Leigh wrote:
> Noah Misch <address@hidden> writes:

> My thought was if $CC contains odd characters, or space in the path.
> We shouldn't break on spaces.  It's best if sed isn't required at all.

That `sed' poses no risk to odd characters in $CC.  $CC is input, not part of
the `sed' script.

> It also makes configure even slower on some platforms (e.g. Cygwin,
> where fork() has an overhead measured in seconds of wall clock time,
> and configure scripts already take at least 20 minutes to run!)  This
> isn't a big deal, though.

The extra fork is unfortunate.  If there is a way to avoid it without
sacrificing semantics, that would be great.

Maybe folks who spend twenty minutes on one `configure' run should pull a 100
MHz Pentium from a dumpster and install GNU/Linux.  Then save the Cygwin-bound
world by hacking `ash' to use `spawn' and build-in `sed', `grep', and `expr'.

> > AC_PROG_CC       # CC := cc -foo89
> > CC="$CC -bar"    # CC := cc -foo89 -bar
> > AC_PROG_CC_STDC  # CC := cc -bar -foo99
> >
> > Not a big deal, to be sure, but it worked with former definitions of 
> > AC_PROG_CC
> > and AC_PROG_CC_STDC, so we may as well not break it.
> 
> For the steps above, wouldn't the following work?  I've added an extra
> $CC_EXTRA variable to accomodate what you want.

The developer must change his configure.ac to use that.  I will never write
something like that example in a configure.ac, but developers who have done so
should not get different behavior when they bootstrap with Autoconf 2.60.  Not
to avoid one fork per `configure' run.

Your CC_COMPILER idea would be excellent if a new name, not AC_PROG_CC_STDC,
aliased the macro that prepares the compiler to interpret code with respect to
the latest C standard.  Then there would be no backward compatibility problem;
we could document the fact that AC_PROG_CC_C99 discards changes to `CC' between
AC_PROG_CC and AC_PROG_CC_C99.

Furthermore, my patch is academic unless there exists a $CC to which both
AC_PROG_CC_C89 and AC_PROG_CC_C99 would add a flag, and that $CC rejects an
invocation bearing both of those flags.  I suspect that every $CC that can be
made to accept most C99 language features with the right flag will accept
function prototypes without any option.  If that is the case, there is no reason
to strip out $ac_cv_prog_cc_c89 in the first place.