[M3commit] CVS Update: cm3

[Tony Hosking]

I'm about to check in a version that achieves what you want based on  
M3_BACKEND_MODE in cm3.cfg without the nasty hack of hardwiring cm3.

On Jan 7, 2008, at 4:10 PM, Jay wrote:

>
>
>> 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