Re: use CPPFLAGS at configure time

[Alexandre Oliva <aoliva at redhat dot com>]

On Apr  4, 2003, Roland McGrath <roland at redhat dot com> wrote:

>> The bug I'm trying to fix here is that C compiles, and even
>> preprocessing, aren't always using CPPFLAGS in the configure tests.

> I have checked in configure changes to make it consistent throughout.

Thanks.

>> I'm out of options.

> You are trying to wedge in a special case that does not fit into the GNU
> conventions properly.  We won't help with that.  If you want to get the
> special case CC hackery into Autoconf, we won't stop you.

There's no special-case CC hackery to be done.  All I need is a flag
to be passed to the compiler whenever compiling or linking something.
I can add it to CC or CFLAGS, but setting either of them if they're
previously unset requires duplication of the autoconf logic to find
set CC and CFLAGS.  I.e., CC, if unset, is set to gcc on native
compilations, or <host>-gcc on cross compilations.  CFLAGS, if unset,
is set to `-O2 -g' if the compiler supports it, and to `-O -g'
otherwise.

What I'm trying to accomplish is to add a flag to either CC or CFLAGS
without rendering autoconf's work useless.  It makes no sense
whatsoever to try to modify autoconf's AC_PROG_CC to that end.  The
triplets that specify an ABI to be used are only there because of
glibc's (or Uli's?) requirements that there must be a way to tell the
full configuration from a triplet.  I'd be more than happy to simply
remove the gnuabi* variants for mips64-linux-gnu and rely on user's
setting of -mabi= in CFLAGS or CC, but I can't do that either.

autoconf has no business doing whatever you think it should be doing
in this case.  These triplets are to satisfy glibc, and autoconf is
not going to be polluted with this junk.

>> The convention is actually that:

> To what do you refer when you speak definitively about "the convention"?  

I'm talking about the behavior of autoconf, automake, GNU make and
other tools that happen to follow the convention.  I don't know of any
better reference than the autoconf and the GNU make manuals for this,
but there may be a common root that both are derived from.  This is
definitely not new.

> I am talking about GNU conventions agreed upon by the GNU project,
> and when not explicitly specified what the long-term and widespread
> traditions have been, not what Autoconf or Automake happens to do
> today.

Autoconf and Automake haven't changed in this regard for as long as
I've been around, which is certainly not as long as you, but still a
relatively long time.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva at {redhat dot com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva at {lsd dot ic dot unicamp dot br, gnu.org}
Free Software Evangelist                Professional serial bug killer