> rhealey> 	First, make is given the knowledge of what hardware
> rhealey> and port it is on via internal variables. I think it IS more
> rhealey> appropriate to handle this via the internal make variables
> rhealey> than having some poorly named symbols, i.e. one's without __,
> rhealey> hard coded in to a compiler.
> 
> NO!  We don't want separate make binaries for cross-compilation.
> That would make writing multitarget makefiles very hard.  The
> predefined defines are target attributes and thus belongs in the
> compiler.
> 
	Hmmm, I wasn't aware the primary goal of NetBSD was to make it's
	tools taylored to a cross compilation environment...

	By the way, it's too late to change this behaviour in NetBSD make,
	it's been in there for 2 months or so... It's only because the
	non-supp'd Amiga trees are so far behind sun-lamp that it hasn't
	been noticed till now.  I believe you can redefine MACHINE and
	MACHINE_ARCH in the makefile if you wish, or override them with
	environmental/command-line variables.

	The compiler should defined 3 things:

	1) __NetBSD__	<- OS
	2) __m68k__	<- Architecture
	3) __amiga__	<- specific machine {__mac__,__sun3__, etc}

	The kernel should be able to figure out what subspecies of CPU
	, 040, 030, 020, 060, etc. without it being hardcoded anywhere. The
	programs that are effected by this should either have the info
	massaged by the kernel, better idea, or massaged by the kvm library,
	which gets the knowledge of CPU from a kernel call.

	It's quite reasonable for make to know all 3 of the above since the
	vast majority of the cases it will be correct, cross compilation
	is the only majoe case where you would want to override and that's a
	small percentage of the total of all makes run by all people.

		-Rob

------------------------------------------------------------------------------