On Fri, 24 Dec 1999, Frank van der Linden wrote:

> I've been looking into getting cross-compiling between different NetBSD
> platforms in the tree by default. The inspiration for this was a script
> by Bill Sommerfeld, which showed that all the mechanisms are basically
> already there; setting some make/environment variables is enough to
> create the crosscompilers, and do a cross-build.
> 
> I took the following approach:
> 
> 	* Call the cross-compile targets <machine>-<format>, e.g.
> 	  i386-elf, i386-aout, sparc-elf, alpha-elf. Just the machine
> 	  name (e.g. "alpha") will point to the currently used format
> 	  for that architecture.
> 	* For different ports that have the same CPU type (e.g.
> 	  the m68k ports), a different machine/ include dir will
> 	  be used.
> 	* in src/gnu/cross, create reachover trees for each of these
> 	  targets, and targets to install the different machine/
> 	  include dirs.
> 	* Supply script frontends called x<toolname> that accept
> 	  a "-target X" argment. I.e. there will be xcc, xas, xld
> 	  xstrip, xnm and possibly xmake. These frontends will invoke
> 	  the right crosstools, supplying the additional arguments
> 	  needed (like -B and -I for cc).
> 
> My current layout is:
> 
> 	/usr/cross
> 		i386-elf
> 		i386-aout
> 		sparc-elf
> 		...
> 			libexec/
> 				cc
> 				as
> 				ld
> 				cc1
> 				cc1plus
> 				...
> 			lib/
> 		include/
> 			i386/
> 			alpha/
> 			...
> 				machine -> .
> 				param.h
> 				...
> 				m68k-> ../m68k (for m68k ports)
> 
> 	/usr/bin
> 		xcc
> 		xld
> 		xas
> 		...
> 
> Note: cc, ld and as are in libexec because 1) they will never be executed
> directly, only through a script, and 2) when invoked with -B, gcc expects
> everything it invokes to be in the directory specified with -B.

I like it, except I think we should be doing it though the package system.

Why? So you can easily choose to install what you want and don't want.

While I think it's great/important for us to support cross compilers in a
more intemate way than we do now, since the base system isn't modularized
like the package system is, I don't think we should put it in the base
source.

So what I'm suggesting is basically taking what you describe above, adding
a PLIST to it, and putting it in a special cross package category.

Note: these cross-compilers would be different from the ones pkgsrc has
now in that they REQUIRE a NetBSD source tree (they'd reach over). The
ones in pkgsrc right now fetch gnu distfiles and build out of there - they
DON'T require NetBSD source. :-)

> Open issue: do we always want the full lib directory for the target archs
> to be installed? It's not strictly necessary, you can do "make builds"
> without them, but I'd like people to be able to do
> "xcc -target m68k -o foo foo.c" and have it work.

With packages, it's easy. If you want includes, you add the includes for
your target arch. If you want libs, you add those.

One other advantage of this is that the includes and libs packages form a
vector, not a matrix. i.e. there'd be one per target arch, not one per
target and per host arch.

From looking around, we're now up to the following architectures: alpha,
arm32, i386, m68k, ns32k, mips, powerpc, sparc, sh3, and vax. So we're
talking about adding 9 cross-compilers to a default build (10 arch's - the
one you're on). That seems a bit much. And our hope is to make this list
grow with time! :-)

With packages, you can pick and choose the ones you want. If you want them
all (like I will in some systems), you get them all. If you want one, you
get one.

Just my thoughts.

Take care,

Bill