On Thu, 18 Oct 2001, Jason R Thorpe wrote:

> 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).

That's true, though not what you were initially complaining about.

>  They're not really sparc64
> objects -- they're i386 objects, so putting them into obj.sparc64 is
> also wrong conceptually.

I tend to think that that's what the ".lo" is all about.  I don't think
that this is confusion over the meaning of MACHINE, though.  MACHINE still
refers to the target, but it turns out not to be enough.

>  > 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.

Doesn't that also have to be set in the environment?

>  > > 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".

Heh.  If our only problem with cross-compiling is that something is
non-intuitive, I think we're doing well.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>