[M3commit] CVS Update: cm3

[Jay Krell]

CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	07/11/30 12:32:01

Modified files:
	cm3/m3-win/import-libs/src/: m3makefile 
	cm3/scripts/win/: clearenv.cmd sysinfo.cmd 
	cm3/m3-sys/cminstall/src/config/: NT386 

Log message:
	config/NT386:
	guide delayload use by environment variable USE_DELAYLOAD, 0 or 1
	guide msvcrt.lib vs. libcmt.lib use by environment variable USE_MSVCRT, 0 or 1
	(didn't actually test with a toolset that lacks libcmt.lib, but 7.1
	Express Edition is one to try but test with Visual C++ 2.0 that lacks
	/delayload)
	
	clearenv.cmd:
	clear more stuff, maybe too much, we'll see
	
	sysinfo.cmd:
	probe for /delayload and msvcrt.lib by running link
	a la autoconf
	inefficient!
	better options perhaps include:
	have cm3.exe split %LIB% and look for delayimp.lib/msvcrt.lib/libcmt.lib
	run link | findstr Version, just running link and findstr once,
	and base /delayload decision on it
	a solution that works with older cm3.exe is perhaps desirable
	a solution that doesn't require version knowledge is perhaps desirable,
	though since it could be a >= thing, and not a table listing all known
	versions, maybe ok
	a manual "configure" step that user runs when user decides it is needed
	may also be preferable, but that has shortcomings, what does it take
	to switch toolsets? Do you hash the environment and store all the
	configurations?
	The current "inefficient" solution runs fairly quickly in practise,
	relative to how slow do-pkg et. al. already are.. this all needs rewriting
	in Modula-3 perhaps if only I could bring myself to actually like Modula-3..
	I don't even like cmd (Perl is way better as a general purpose programming
	language...)
	
	import-libs/src/m3makefile
	sleazy: fix the path to my local Visual C++ 2.0 so I use it to make import
	.libs; this is for a hypothetical binary distributation that works with "all"
	toolsets, except it isn't actually sufficient I found tonight, as, e.g.
	m3.lib output from a newer toolset doesn't work with older toolset