Subject: Re: Bi-endian platforms and build.sh
To: Jason R Thorpe <firstname.lastname@example.org>
From: Simon Burge <email@example.com>
Date: 12/11/2002 16:39:46
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 :-)
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
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;;
> ...and I'd rename "bi_endian" to "multi_arch" ... because that's
> really how we want to think about it.
Simon Burge <firstname.lastname@example.org>
NetBSD Support and Service: http://www.wasabisystems.com/