[M3commit] CVS Update: cm3

[Jay Krell]

CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	06/12/30 08:07:29

Modified files:
	cm3/m3-sys/cm3/src/config/: NT386 

Log message:
	Update compiler and linker flags, prep for changes around .pdb and .manifest files, cleanup some comments, etc.
	
	Many of the previously specified flags are odd and appear to come from an old Windows SDK win32.mak.
	That is not a particularly common way to build things, not a good example to follow.
	It is neither the Windows DDK that resembles the Windows (NT) build enviroment,
	nor it is any version of the Visual C++ IDE.
	
	link /debug means produce a .pdb. Use that.
	
	link /incremental:no is still pretty fast and avoids some warnings I vaguely recall.
	It produces somewhat smaller/faster binaries. It might be nice to expose this at a higher level
	to give users a choice of faster linking. Even the first link is faster without /incremental:no I recall.
	
	compiler: Debug information does not inhibit optimization and though optimized code is somewhat difficult to debug,
	you are still much better off with symbols than without. Therefore always produce debug information.
	
	link /debugtype:cv is surely the default, remove it.
	
	link /pdb:none is nice -- it puts the debug info in the .exe, and comments indicate that Windbg
	required it, but current linkers do not support this option, current Windbg does not require it, no
	Visual C++ GUI debugger ever required it. Remove it.
	
	link /align:0x1000 produces warnings I recall and surely is not necessary.
	Section alignment defaults to 4K == page size. (except Itanium? 8K?)
	File alignment defaults to either 4k or 512 depending.
	4k is better for Win9x perf.
	all NT files use 512 which is smaller and fine for NT perf.
	Whatever this switch does, it is rarely used and not needed here, remove it.
	
	link /debug:mapped -- related to debug information in the .exe, remove it.
	
	link /debug:partial -- I don't know what this did, but debugging is hard enough, let's get whatever "full" information there is.
	
	/Z7 vs. /Zi
	
	With /Zi, the compiler puts type information in a .pdb whose default name depends
	on compiler -- vc50.pdb, vc80.pdb, etc. but which can be renamed like to foo_compiler.pdb with the /Fd switch.
	
	The type information is shared across source/object files. It is smaller/faster.
	
	With /Z7, type information is duplicated in every .obj. This is bigger and slower.
	
	Older linkers by default produce foo.pdb that refereneces vc*.pdb.
	This is why older debuggers often prompt for that file.
	Older linkers have an option /pdbtype that can be /pdbtype:septtypes or /pdbtype:consolidate.
	5.0 has this for example.
	The default is septtypes. Consolidate produces a standalone .pdb.
	
	Newer linkers default to /pdbtype:consolidate and don't have an option to use the old default.
	
	The ideal is to use /Zi and /Fd and with older linkers /pdbtype:consolidate.
	But we don't have configuration that checks the linker version.
	
	For now use /Z7 which always works and produces one .pdb per link output.
	/Z7 also provides for standalone .libs.
	
	Despite being "old", /Z7 is still widely used (see the Windows DDK).
	
	There is very little C compilation in the system anyway so doesn't matter much.
	
	cl /_DLL is implied by cl /MD
	cl /_MT is implied by cl /MT or cl /MT
	/D_DLL informs the C runtime headers that the dynamic C runtime will be linked to.
	/D_MT informs the C runtime headers that a thread safe C runtime will be linked to.
	/D_DLL implies /D_MT at least in principle.
	There are no longer any thread-unsafe C runtimes and /MT is the default.
	
	Unify INITIAL_REACTOR_EDITOR and commented out INITIAL_REACTOR_BROWSER with the
	other copy of this file. I assume this is ok but might result in unexpected prompts.
	
	Prep for using the Visual C++ 8.0 dynamic runtime which requires a little more work.
	There is a new configuration option UseDynamicCRuntime which can be TRUE or FALSE but
	which for now is FALSE. TRUE is working on my machine but requires either a change to cm3
	to copy along .manifest files or running scripts\win\msvcr80.cmd which is new.
	
	Cleanup some comments, whitespace, remove dead commented out code.
	We are dealing with files, not junk.
	
	Comment on the dumb use of a process to rename a file.
	
	Prep for cm3 change that will copy along .pdb files (and .manifests).
	
	.map files are junk, don't produce them.
	
	cl /DWIN32 is needed for old Windows headers (Visual C++ 2.0)
	newer headers use _WIN32 and current compilers #define it by default.
	
	cl /D_X86_ probably is defined by the compiler but I didn't check yet.
	
	Using /Z7 lets us remove the deletion of vc40.pdb (or whatever the .pdb gets named).