On Thu, Oct 18, 2001 at 06:15:43PM +0100, Ben Harris wrote:

 > Erm, won't the first of those build in src/tools/toolchain/obj.i386 and
 > the second in src/tools/toolchain/obj.sparc64?  That's certainly what
 > seems to happen here (s/i386/macppc/;s/sparc64/arm26/).

But that's wrong if you then want to do a self-host on the sparc64 (to
e.g. test pmap stability, or something).  They're not really sparc64
objects -- they're i386 objects, so putting them into obj.sparc64 is
also wrong conceptually.

 > You certainly couldn't get away with just changing objdirsuffix, since
 > make(1) still assumes that every value of getenv("MACHINE") will have a
 > distinct objdir, and you seem to be leaving MACHINE representing the host.

You could then set MAKEOBJDIR to obj.$objdirsuffix which would then
cause make(1) to DTRT, I believe.

 > > Anyway, this would then allow a builder to simply set TARGET_MACHINE
 > > and TARGET_MACHINE_ARCH, and be able to cross-build the tree without
 > > the weird side-effects of overriding MACHINE and MACHINE_ARCH.
 > 
 > What side-effects are these?  I've seen very few problems doing this kind
 > of thing myself, and working on the assumption that MACHINE and
 > MACHINE_ARCH represent the target.

See above -- "non-intuitive to have i386 objects in a directory called
obj.sparc64".

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>