[M3commit] CVS Update: cm3

[Jay]

> Thus, controlling the backend is a simple matter of changing the cm3.cfg



Exactly.


What I have right now is I build an NT386/Win32 cm3, and then I change the config file, and that one cm3 switches between gcc or not.
It is a hybrid.
I can already compile all of m3core with this cm3/m3cg, except for threading.
I also copy the NT386 directories in pkg to NT386GNU, and possibly foo.lib to libfoo.a -- I have to try again to see if that was the key or not.
This gives me an easier sort of "cross", on one machine/OS.

I actually swap out the entire cm3.cfg, cm3/m3-sys/cminstall/config/NT386 vs. cm3/m3-sys/cminstall/config/NT386GNU, not just one line.

I'll try the "mode" and look at pm3. Thanks.


 > threading

Yeah I thought Win32 would work. I'll try/look again. Later.
I think it was set for Posix/setjmp/longjmp and I think I tried pthreads, might not have tried Win32.

 - Jay

> From: hosking at cs.purdue.edu
> Date: Mon, 7 Jan 2008 15:27:30 -0500
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> Also, following up on your changes for the backend.  I suggest you  
> take a look at the way things are handled in the M3BackLinux.m3 code  
> for PM3.  You should be able to switch between the integrated backend  
> and the gcc-based backend similarly, based on the value of the  
> M3_BACKEND_MODE flag.  Thus, controlling the backend is a simple  
> matter of changing the cm3.cfg.
> 
> 
> 
> On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote:
> 
> > 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
> >
> 

_________________________________________________________________
Watch “Cause Effect,” a show about real people making a real difference.
http://im.live.com/Messenger/IM/MTV/?source=text_watchcause
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20080107/a75411ba/attachment-0002.html>