[M3commit] CVS Update: cm3

[Jay Krell]

CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	08/12/31 11:52:08

Modified files:
	cm3/m3-comm/netobj/src/: netobj-ov.tmpl 
	cm3/m3-comm/sharedobj/src/: sharedobj-ov.tmpl 
	cm3/m3-libs/libm3/src/bundleintf/: bundle-ov.tmpl 
	cm3/m3-ui/zeus/src/: m3zume-ov.tmpl 
	cm3/m3-ui/juno-2/juno-app/src/: m3makefile 

Log message:
	Partly kinda sorta fix some cross build scenarios, without
	affecting native builds.
	
	It's a larger more general problem though.
	
	- BUILD_DIR does not necessarily equal HOST or TARGET,
	because of how I structured I386_CYGWIN to be a "configuration"
	where TARGET is still NT386.
	
	- a cross build can run the shipped binary anyway,
	and probably should (I didn't have the unshipped binaries around)
	
	- There should probably be automation to ensure all the tools are build.
	ie: do-cm3-tools or do-cm3-crosstools. ie: build just the needed packages,
	for the sniffed native platform.
	
	Cross builds have other problems.
	
	I keep hitting the following annoyances:
	
	ignoring foo/bar override when foo\bar already overridden
	override paths should either be canonicalized to one slash type
	or at least when there is a duplicate, canonicalize then and only
	complain if canonicals vary
	This is due to mixing I386_NT and I386_CYGWIN.
	Similarly the problem demonstrated regarding m3unix.h in Uwaitpid.quake.
	
	Perhaps the change I made to allow forward slashes on Win32 was not good, esp. due to
	its apparent inadequacy.
	
	The "lib" directory, specifically \cm3\lib\hand.obj is target..er, configuration dependent
	the gcc hand.obj cannot be directly linked by Visual C++, for reasons to do with libgcc
	
	lib should probably have "target" or "build_dir" under it
	
	and/or hand.obj specifically should be merged into m3core.lib
	
	The mentor quake code generally fails in cross environments, probably due to slashes.
	
	host=NT386 (GNU?), target=LINUXLIBC6 m3zume is access violating
	
	I'm also highly suspicious of all this "override" stuff.
	It clearly causes too much duplication and distribution of information.
	I shouldn't have to know the directory structure of my dependencies,
	and even if I do, I should be able to share that knowledge with their many
	other dependents. The "scripts" directory also figures this sort of stuff out automatically..
	Being able to have multiple package stores is well and good.
	I'm not sure they need to ever be used in an "unshipped" form, but instead just
	use alternate roots and create new empty roots as needed. ?