[M3devel] [M3commit] CVS Update: cm3

[Tony Hosking]

Jay, I am very nervous about the pervasive nature of some of your  
recent commits.  NT386GNU is usually configured with  
OS_TYPE="POSIX".  Thus, the m3makefile for cm3, which contains the  
following:

if equal (OS_TYPE, "POSIX")
   interface ("M3Backend")
   implementation ("M3BackPosix")
   implementation ("UtilsPosix")
else
   import ("m3objfile")
   import ("m3back")
   interface ("M3Backend")
   implementation ("M3BackWin32")
   implementation ("UtilsWin32")
end

will build a POSIX backend for you on NT386GNU which should do the  
right thing in invoking the gcc-based backend.  Your changes, which  
hardwire things in cm3 for NT386GNU are thus unnecessary.   I suggest  
you back these changes out and reconsider things.  Certainly,  
NT386GNU should be considered as an independent POSIX target from the  
NT386 WIN32 target.  Thus, one need not make changes to M3BackWin32  
for NT386GNU, since it is treated as a POSIX target.

As far as threading goes, if user-level threading for NT386 does not  
work then I can imagine it would be OK to use native WIN32 threads.   
The switch for that is in m3core/src/thread/m3makefile, which would  
check for TARGET="NT386GNU" and choose sibdirectory WIN32 instead of  
using OS_TYPE to pick subdirectory POSIX.

On Jan 7, 2008, at 8:38 AM, Jay Krell wrote:

> CVSROOT:	/usr/cvs
> Changes by:	jkrell at birch.	08/01/07 08:38:15
>
> Modified files:
> 	cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3
> 	                                     Utypes.m3
> 	cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3
> 	                     M3BackWin32.m3 M3Backend.i3
> 	cm3/m3-sys/cminstall/src/config/: NT386GNU
> 	cm3/m3-sys/m3front/src/misc/: M3Front.m3
>
> Log message:
> 	some fixes for NT386GNU (cygwin)
> 	
> 	let win32 cm3 use the gcc backend if target == NT386GNU
> 	might need a better interface here?
> 	switching on target name is probably the wrong thing
> 	need something called "use gcc backend" or somesuch
> 	
> 	loosen the check for file name vs. module name to account for  
> paths with both types of slashes
> 	might need a better interface/implementation here?
> 	should try to get the paths to line up instead?
> 	
> 	remove -fPIC since it warns that it is redundant (though the  
> warning is probably wrong
> 	in other details -- not all code is position independent, merely  
> relocatable..)
> 	
> 	use configured ar, /usr/bin/ar doesn't work, just plain ar does
> 	
> 	update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON
> 	
> 	update Uresource.i3 from struct_rusage_start to VAR struct_rusage
> 	
> 	fix warning about unused import long in Utypes.m3
> 	
> 	change SYSTEM_CC from cc to gcc because cc is something on my system,
> 	that I have not investigated, and doesn't work; gcc is perfectly  
> ok here, though
> 	cc lines up nicely with the other two character names -- ar and as
> 	
> 	now need to deal with threads to get m3core to build