<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'><div style="text-align: left;"><br>
> Thus, controlling the backend is a simple matter of changing the cm3.cfg<br>
<br>
Exactly.<br>
<br>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.<br>It is a hybrid.<br>I can already compile all of m3core with this cm3/m3cg, except for threading.<br>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.<br>This gives me an easier sort of "cross", on one machine/OS.<br><br>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.<br><br>I'll try the "mode" and look at pm3. Thanks.<br>
<br> > threading<br><br>Yeah I thought Win32 would work. I'll try/look again. Later.<br>I think it was set for Posix/setjmp/longjmp and I think I tried pthreads, might not have tried Win32.<br><br> - Jay<br><br></div><hr id="stopSpelling">> From: hosking@cs.purdue.edu<br>> Date: Mon, 7 Jan 2008 15:27:30 -0500<br>> To: hosking@cs.purdue.edu<br>> CC: m3devel@elegosoft.com; m3commit@elegosoft.com<br>> Subject: Re: [M3commit] CVS Update: cm3<br>> <br>> Also, following up on your changes for the backend. I suggest you <br>> take a look at the way things are handled in the M3BackLinux.m3 code <br>> for PM3. You should be able to switch between the integrated backend <br>> and the gcc-based backend similarly, based on the value of the <br>> M3_BACKEND_MODE flag. Thus, controlling the backend is a simple <br>> matter of changing the cm3.cfg.<br>> <br>> <br>> <br>> On Jan 7, 2008, at 3:16 PM, Tony Hosking wrote:<br>> <br>> > Jay, I am very nervous about the pervasive nature of some of your <br>> > recent commits. NT386GNU is usually configured with <br>> > OS_TYPE="POSIX". Thus, the m3makefile for cm3, which contains the <br>> > following:<br>> ><br>> > if equal (OS_TYPE, "POSIX")<br>> > interface ("M3Backend")<br>> > implementation ("M3BackPosix")<br>> > implementation ("UtilsPosix")<br>> > else<br>> > import ("m3objfile")<br>> > import ("m3back")<br>> > interface ("M3Backend")<br>> > implementation ("M3BackWin32")<br>> > implementation ("UtilsWin32")<br>> > end<br>> ><br>> > will build a POSIX backend for you on NT386GNU which should do the <br>> > right thing in invoking the gcc-based backend. Your changes, which <br>> > hardwire things in cm3 for NT386GNU are thus unnecessary. I <br>> > suggest you back these changes out and reconsider things. <br>> > Certainly, NT386GNU should be considered as an independent POSIX <br>> > target from the NT386 WIN32 target. Thus, one need not make <br>> > changes to M3BackWin32 for NT386GNU, since it is treated as a POSIX <br>> > target.<br>> ><br>> > As far as threading goes, if user-level threading for NT386 does <br>> > not work then I can imagine it would be OK to use native WIN32 <br>> > threads. The switch for that is in m3core/src/thread/m3makefile, <br>> > which would check for TARGET="NT386GNU" and choose sibdirectory <br>> > WIN32 instead of using OS_TYPE to pick subdirectory POSIX.<br>> ><br>> > On Jan 7, 2008, at 8:38 AM, Jay Krell wrote:<br>> ><br>> >> CVSROOT: /usr/cvs<br>> >> Changes by: jkrell@birch. 08/01/07 08:38:15<br>> >><br>> >> Modified files:<br>> >> cm3/m3-libs/m3core/src/unix/cygwin/: Umman.i3 Uresource.i3<br>> >> Utypes.m3<br>> >> cm3/m3-sys/cm3/src/: Builder.i3 Builder.m3 M3BackPosix.m3<br>> >> M3BackWin32.m3 M3Backend.i3<br>> >> cm3/m3-sys/cminstall/src/config/: NT386GNU<br>> >> cm3/m3-sys/m3front/src/misc/: M3Front.m3<br>> >><br>> >> Log message:<br>> >> some fixes for NT386GNU (cygwin)<br>> >> <br>> >> let win32 cm3 use the gcc backend if target == NT386GNU<br>> >> might need a better interface here?<br>> >> switching on target name is probably the wrong thing<br>> >> need something called "use gcc backend" or somesuch<br>> >> <br>> >> loosen the check for file name vs. module name to account for <br>> >> paths with both types of slashes<br>> >> might need a better interface/implementation here?<br>> >> should try to get the paths to line up instead?<br>> >> <br>> >> remove -fPIC since it warns that it is redundant (though the <br>> >> warning is probably wrong<br>> >> in other details -- not all code is position independent, merely <br>> >> relocatable..)<br>> >> <br>> >> use configured ar, /usr/bin/ar doesn't work, just plain ar does<br>> >> <br>> >> update Umman.i3 MAP_ANONYMOUS to new shorter name MAP_ANON<br>> >> <br>> >> update Uresource.i3 from struct_rusage_start to VAR struct_rusage<br>> >> <br>> >> fix warning about unused import long in Utypes.m3<br>> >> <br>> >> change SYSTEM_CC from cc to gcc because cc is something on my <br>> >> system,<br>> >> that I have not investigated, and doesn't work; gcc is perfectly <br>> >> ok here, though<br>> >> cc lines up nicely with the other two character names -- ar and as<br>> >> <br>> >> now need to deal with threads to get m3core to build<br>> ><br>> <br><br /><hr />Watch “Cause Effect,” a show about real people making a real difference. <a href='http://im.live.com/Messenger/IM/MTV/?source=text_watchcause' target='_new'>Learn more</a></body>
</html>