[M3commit] CVS Update: cm3

[Tony Hosking]

I went ahead and cleaned things up to be based on M3_BACKEND_MODE  
instead of the overly-hardwired approach you were using.

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. Learn more