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

> On Sat, Apr 28, 2001 at 04:19:47PM +0100, Ben Harris wrote:
>
>  > object formats (e.g. the various m68k ports at the moment), so objdirs
>  > should be named based on the (MACHINE_ARCH, OBJECT_FMT) tuple.
>
> Actually, I'd like to go just a little further, here.
>
> I just filed a PR yesterday indicating a problem with building
> cross-toolchains in the USE_NEW_TOOLCHAIN case .. in particular,
> consider:
>
> 	* Have native i386--netbsdelf toolchain built in src/tools (and
> 	  its objdirs).
>
> 	* Want to build i386 -> sparc64--netbsd toolchain in src/tools,
> 	  and leave the native toolchain intact.

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

> Then, you can do something clever like:
>
> if $HOST_MACHINE_ARCH != $TARGET_MACHINE_ARCH
> 	objdirsuffix = \
> 	    ${HOST_MACHINE_ARCH}-${TARGET_MACHINE_ARCH}-${TARGET_OBJFMT}
> fi
>
> Or just assign it to the triple all the time and be done with it.

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.

The problem, as I see it, is that make has an excessively-fixed idea of
where its objdir is.  It's obj.${MACHINE}, and it decides this before it
loads any Makefiles.  We really need it to vary by file (not even by
directory, ideally):

Machine-independent objects (e.g. man pages) using a constant objdir.
Machine-dependent objects (compiled programs) using something based on
${TARGET_MACHINE_ARCH} and ${TARGET_OBJFMT}.
Target-independent host tools (e.g. groff) using something based on
${HOST_MACHINE_DESCRIPTION}.
Target-dependent host tools (e.g. gcc) using something based on
${HOST_MACHINE_DESCRIPTION}, ${TARGET_MACHINE_ARCH} and ${TARGET_OBJFMT}.

Note that ${HOST_MACHINE_DESCRIPTION} is not just ${MACHINE} or
${MACHINE_ARCH}, since we also depend on the OS version, and the OS may
not even be NetBSD.  The tricky thing is getting all this information into
make early enough for it to pick the objdir based on it.

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

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