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:

>> 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.

> If you need that done when running configure checks, then you need
> to hack CC.

It has always been the case that CPPFLAGS and CFLAGS are both used
uniformly in all configure tests that use CC.  Glibc is the first
package I've seen that uses autoconf but doesn't follow this
practice.

As for hacking CC, that was exactly what my first patch, posted on Jan
15, did.  You asked me to find another way to accomplish this because
I introduced a variable whose contents were appended to $CC.  It
turned out both CPPFLAGS and CFLAGS should have similar effect, and
since CC and CFLAGS have defaults set by AC_PROG_CC, I decided to use
CPPFLAGS, just to find out that glibc didn't use it uniformly.

I would very much like to revert to the original patch I had, that
consisted of setting a variable to an empty string before:

# Expand the configuration machine name into a subdirectory by architecture
# type and particular chip.

then I'd set this variable in the mips64* section, and, after
AC_PROG_CC, I'd append its contents to CC.

What is the bad point about it?

If this is indeed rejected, I'll just resort to using CFLAGS instead
of CPPFLAGS, which is indeed the right thing to do, but will require
me to assume that CFLAGS would be set to -g -O2 by AC_PROG_CC, if not
previously set.  I.e., I'd do:

		  CFLAGS=${CFLAGS-"-g -O2"}" -mabi=$mips_config_abi"

>> 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.

> This is not some spurious invention to make your life difficult, Alexandre.

I understand its purpose is not to make my life difficult, but it is a
spurious invention.

> This has always been the fundamental purpose of GNU configuration tuples.

The tuple doesn't determine everything there is to be determined on a
platform.  It never has.  I've already given the examples in which
this theory that a tuple determines everything about a platform falls
down, but I'll do it again, with some additional examples:

mips-sgi-irix6.5 is a tuple of a platform that supports 3 ABIs, just
like mips64-linux-gnu.  There's no tuple for the separate ABIs, and
there shouldn't be.

There's no tuple that corresponds to `alpha-linux-gnu-gcc -mieee', the
tuple is still alpha-linux-gnu.

sh-elf is a tuple that determines a set of dozens of different ABIs,
targeting 6 different machine types, some of which support several of
these ABIs.

Saying the tuple is supposed to determine the ABI is a failure to
notice there's something more that systems that support a single ABI.

It has never been the intent that the configuration tuple introduces
certain compiler, assembler, linker or whatever flags to match what
the tuple says.  It has never been the intent that tuples duplicate
information that has to be provided in the form of such options
either.  The intent is that tuples define a platform, and, if you need
to choose one of the features (say ABIs) supported by the platform,
that is not the default ABI of the toolchain you're using to build it,
you use one of the environment/make variables to tell the build system
what to do, and this doesn't make the platform a different platform.
It's still the same machine, from the same vendor, running the same
operating system, therefore the same triplet.  It's just a different
configuration of the same platform.

Trying to force the existence of such triplets just to satisfy glibc
requirements is indeed a requirement derived from a distorted view of
what a tuple means, and it does indeed make my life difficult.

> The whole reason to have invented such a convention all those years ago was
> so that code just like what we have in glibc could be written safely by
> making the assumption that the tuple is a useful identifier.

There's no safety being obtained by such assumption.  Saying the tuple
is foo-bar-x-variantz won't do you any good unless you also use a
compiler with flags that enable variantz.  And if you have to use
those flags anyway, what's the point of duplicating this information
in the tuple?  Try to get reasons to blame the user for not doing the
right thing? :-)   That's silly.  Requiring information to be given
twice serves no purpose other than making room for incompatibilities
between the specification.  Getting such information from a single
place would be far more robust.  Having several options means you
have to check for incompatibilities, or let problems go undetected.
If you ask me, either way is broken.  The information is to be given
in a single place, and the tuple name is not it because it doesn't
affect the behavior of the toolchain.  Doing it the other way round,
i.e., deriving configuration information from flags passed to the
toolchain is far more robust, as long as the flags are actually used
at build time, and not only at configure time.

However, taking the robust path requires a difficult step: letting go
of the incorrect assumption that a tuple is enough to determine
everything there is to be determined about a platform.  The
alternatives are forcing people to come up with artificial tuple
names, that are going to be used in glibc and nowhere else, which, as
a side effect, reduces the robustness of the configuration, instead of
increasing it, due to the inability of the configure system to verify
whether the given tuple-variant actually matches what $CC $CFLAGS
actually target.

-- 
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