X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10112262228.AA14172@clio.rice.edu>
Subject:	RFD - UNAME_MACHINE ?
To:	djgpp-workers AT delorie DOT com
Date:	Wed, 26 Dec 2001 16:28:30 -0600 (CST)
In-Reply-To:	<10112262044.AA17887@clio.rice.edu> from "Charles Sandmann" at Dec 26, 2001 02:44:06 PM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> 
> > > By the way, we really need some compatibility environment variable 
> > > (or something) to allow uname in 2.04 to provide 2.03 behavior ... 
> > 
> > Why?  What is the problem?
> 
> Older sources (read much of what's on Simtel today in source) won't build 
> using the new uname without hacking.  Someday I see wanting to build some 
> of these with CVS/2.04 release without needing to hand replace images like
> uname.  It would be convenient to have a flag in the environment to fall
> back to machine being "PC" instead of i?86.
> 
> When building with 2.03 this is OK (unless a new distribution requires the
> new uname...), but contrary to popular belief we will get 2.04 released 
> someday :-)

Another example - non-support of i786 / i886 whatever - if we had an 
environment variable which could override, then you could set it to be
i686 and continue.

How about an environment variable UNAME_MACHINE - if defined we use it
instead of the CPU detection?  Allows you to make it "pc" for old v2.03
compatibility or "i586" for builds that don't know about new chips.

- Raw text -