Why does config.guess come up with such wacky stuff?

[Mike Hopkirk(hops)]

On Wed Dec 01,1999 (03:00:02PM -0600), robertlipe@usa.net(Robert Lipe) wrote:
> Mike Hopkirk(hops) wrote:
> 
> > Well its a sort of philosphy thing - the open source philosohy is
> > that you build on what you run on ... Our experience has been that if
> > you're building for arbitrary distribution what you build on varies
> > and this can cause architecture version dependency problems.
> 
> I posit that those building distributions are better qualified to
> understand the issues involved and override the defaults than the
> typical "download the tarball. type configure. type make" user.

sure but its one more thing to remember to do - o well thats my problem 

I guess the question comes down to who do you want/need to cater to more?
    Those that build and run their own downloads (singletons), Those that
    build dists for use by others ( single or multiple architectures),
    any, all, none, .. 

> ...

> > OTOH I can make a case that if an app really cares about the specific
> > architecture to build to (of which gcc is the only example to date)
> 
> I'd agree.   But GCC is Really Important. :-)

yes
 
> > it should be defaulting to the widest coverage unless told different
> > specifically or if it is going to assume you want the max optimisation
> > oriented to the build platform it should be specifically checking for
> > itself to override the guessed values ....
> 
> gcc/configure.in gets told "--target=blah".  From what I can see, it
> doesn't know if 'blah' was created by the user (in which case override
> would be evil) or by config.guess.  So having it second guess the
> triplet sounds risky and like a maintenance problem; we're trying to
> avoid the duplication by synching it against autoconf, not increase it.
> 

sounds like two problems

Getting the specific information portably 
storing/using it from generic info in a way thats distinguishable..

The first could arguably be a function of config.guess, 
the second is up to the app 
 
> > > case `uname -X | egrep '^Machine` in *i80486) UNAME_MACHINE=i486;;
> > > *Pentium$) UNAME_MACHINE=i586;; *PentII*) UNAME_MACHINE=i686;; esac
> >
> > Like OSr5 does.. as I say my original opinion was that way - I was
> 
> Yes, like OpenServer.
>    And like Linux.   

Well thats a extremely convincing point..
If any of the *BSD's do it (or intend to) you've could say I'm more convinced 
we should change it ..
 
> > Convince me its useful and won't cause work/problems for multiple
> > widespread cases not just for gcc - I'll play devils advocate...
> 
> Oh, I'm playing both sides, too.    :-)
> 
> Earlier you said that GCC was the only package that _really_ cared about
> the CPU field.  If we unlock it we have pathnames "floating" but things
> are more likely to work better by default for more users of GCC.

For those that build gcc and run on what they build on and 
don't redistribute their built binaries.

> Do the other packages ever have user-visible data (not private libs as
> in the case of Perl or even GCC) that reflect this field?  

Havent come across a large number to date but I don't play with the entire 
range of Open Source software - Perl is the most indicated/obvious
 case and its irrelevant to this

> If not, we're
> no worse off than we are today where GCC's config.guess defaults to a
> very different format on UW7 than the autoconf config.guess does.
> 
> I think we need to revisit the locked CPU decision.  Can you set up an
> (internal) discussion on this?

sure
    poke it out to me, rr, jkj, allanc

...

-- 
- hops

Everything disclaimed (including disclaimer)
------<hops@sco.com>--------------------------------------
Mike Hopkirk (hops)  |       Whenever possible steal code.
SCO Inc              |          Tom Duff. (ex) Bell Labs