This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: config.sub pentium2 and pentiumii aliases (fwd)


> From: Joe Buck <jbuck@racerx.synopsys.com>
> To: bje@cygnus.com (Ben Elliston)
> Date: Wed, 8 Nov 2000 21:48:27 -0800 (PST)
> Cc: mmckinlay@gnu.org (Mo McKinlay), tege@swox.com (Torbjorn Granlund),
>         gcc@gcc.gnu.org, user42@zip.com.au


> >      > Some packages might want to make a distinction between exact CPU
> >      > types.  GMP is one such package, where there has a very significant
> >      > speed advantage,
> ...

> > I believe that what is required is a carefully selected middle ground:

> I don't think that your middle ground approach is workable
> information provided will not be usable.  AMD's processors don't
> look like "i686", they have different scheduling models

This is wrong.  There is a middle ground.  First, the output, the
config triplet is entirely arbitrary in in theory can be _anything_.

It is just a convenient if it conveys what most people want.  If it
doesn't, then autoconf is responsible for probing any other
information that a software package may want (including package
specific probs), otherwise that information has to be presented by
some other mechanism (--with/--enable).

For example, it is wrong for me to say that the config triplet must
contain such vital information as wether or not X11 is present, or if
mmap works, or if gettimeofday is present, or if the processor is an
AMD variant, or has 3DNow, or is the chip has SIMD support, or if it
is a pentium and not a 386, or if we want to use GNU as, or if we want
to use stabs.  Yes, all these are entirely optional.  We can logically
go either way.  Further, no matter what way we go, we screw people.
If we introduce pentium, suddenly all software that previously checked
for i[3-9]86 might then be broken and might require fixing before it
worked again.  This is the cost of _changes_ to any config triplet.
Such changes should be weighed carefully.  If we piss off too many
people that use triplets from config.guess, they may just stop using
it.  We want to make it nice to use for most people.  There will be
special cases that will require and want more from it, but we should
be careful to not let the tail wag the dog in this case.  We are but
one highly specialized user.  The triplet will _never_ contrain all
the information we want about the system we want to configure for,
further it can never.  The existence of --enable --with and other
various options to control various choices are an example of all the
things that can be claimed to _must_ be in the triplet, but as I have
said, this is wrong, they are all arbitrary.

Notice how Joe says that config.guess should make special concessions
to gcc, just because.  He talks about scheduling parameters, come on,
this is only relevant to a _highly_ specialized piece of software,
100.0% (only accurate to 3 significant digits) of the software doesn't
directly care about scheduling parameters.  This is what I mean my
tail wagging the dog.  If you cannot defend the choice in the context
of 20 other packages that use config.guess, don't be so quick to make
the argument.  If the change isn't desired by more than 1% of the
users of config.guess, maybe the config.guess maintainer _should_ push
back and say, well, I polled my users, and most of them don't need
that information, why don't you just get along without it.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]