Jason R Thorpe wrote:

> On Wed, Dec 11, 2002 at 03:22:56PM +1100, Simon Burge wrote:
> 
>  > I originally had a check for $opt_a, but this doesn't work for the case
>  > where we inherit MACHINE_ARCH from the environment so we want to test
>  > for non-valid values of MACHINE_ARCH.  The idea was to have:
>  > 
>  > 	mips|sh3|sh5)
>  > 		blah blah blah
>  > 
>  > "arm" (that you mention below) does sort of throw a spanner into that
>  > idea though.  How can we better handle this?
> 
> Just unset MACHINE and MACHINE_ARCH at the beginning of the script?  I
> mean, is build.sh documented to work by inheriting those from the environment?
> 
> (Answer: If it is, it should be changed not to do so :-)

From BUILDING:

   Environment variables
     Several environment variables control the behaviour of NetBSD builds.

     MACHINE           Machine type.

     MACHINE_ARCH      Machine architecture.

Should it be changed to not inheriting these?  There is a:

	if [ -z "$MACHINE" ]; then
	...
	MACHINE=`uname -m`

fragment, so I can't overly see the point of picking MACHINE and
MACHINE_ARCH from the environment.

>  > `Feh'.  Ok, I'll break it out to
>  > 
>  > 	mipseb)	BUILDID=eb;;
>  > 	mipsel)	BUILDID=el;;
> 
> Nono... I'm thinking for now you can just go ahead and do:
> 
> 	case $MACHINE_ARCH in
> 	# Add MACHINE_ARCH's that need special handling here.
> 
> 	# And provide a reasonable default for everything else.
> 	*eb)	BUILDID=eb;;
> 	*el)	BUILDID=el;;
> 	esac
> 
> ...and I'd rename "bi_endian" to "multi_arch" ... because that's
> really how we want to think about it.

Ok.

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/