<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
"std" is already essentially "full", or meant to be at least.<BR>
Granted my "std" is missing m3gdb and cm3ide, at least.<BR>
But it isn't small.<BR>
<BR>
<BR>
"std" isn't new or specific to my releases.<BR>
It has been in all the "open" cm3 releases, and probably the Critical Mass ones too.<BR>
<BR>
<BR>
I've been meaning to put together "boot" releases that are perhaps smaller than "min", though that isn't perhaps their defining characteristic. They would consist of assembly code for the Modula-3 and uncompiled C code. Very similar to the old Digital SRC releases, and I think the ezm3 releases. The Digital SRC boot format no longer works, because it depended on quake/m3build/m3ship being written in C.<BR>
<BR>
<BR>
A defining characteristic probably of "boot" is that it is safe against API and ABI changes.<BR>
Another one perhaps though is having to spend the time to build cm3cg.<BR>
My current "boot" archives build only cm3, but extending them to build m3core and libm3 would be trivial, extending them to build all of "std", not too difficult.<BR>
<BR>
<BR>
I gather one of the nice things PM3 had was they shipped IL instead of assembly.<BR>
That can be a a lot more portable, or extremely portable.<BR>
"more portable" -- varying mainly only in wordsize and endian, /maybe/ smaller issues like alignment (almost always the same anyway), page size (not really)<BR>
"extremely portable" -- factor even those out <BR>
Though you'd also have to factor out the Time/Date stuff.<BR>
And if you had user thread support in there, portability gains would be lost.<BR>
This approach, in fact, can lead to "universal posix" distributions, at the cost of user having to build cm3cg. In fact you could build the Win32 code and have the last-on-the-target stage pick the appropriate files, leading to really "universal" distributions.<BR>
<BR>
<BR>
> One sticky issue in the past has been target location<BR>
<BR>
<BR>
This is not an issue with my config files, hasn't been for a long time.<BR>
Kind of bothersome..you know..I solved this years ago..to still be discussing it as an issue..<BR>
Yeah, I realize my ChangeLog is not readable but...<BR>
Quake code can query for its own location.<BR>
At least as of a while ago. Maybe not in much old versions. (I didn't add the feature, I merely discovered it was there.)<BR>
My cm3.cfg file does that.<BR>
And then build the rest of the paths from there -- at least for cm3/cm3cg/pkg/lib.<BR>
<BR>
The location of cl.exe and link.exe aren't solved by path.<BR>
For those, I just run "cl" and "link" and depend on $PATH.<BR>
That's how people often deal with gcc/ld, though I realize there is no unversality here. Some people use full paths to gcc/ld, some rely on $PATH, ditto for cl/link (actually for cl/link, most "people" use an interactive GUI that hides tons of stuff, but there are still "automated builds" that have to do something.)<BR>
<BR>
<BR>
<BR>
I did some experimentation with building a GUI NT install, using "InnoSetup".<BR>
It was just a glorified untargz, which does have some value.<BR>
A little fancier than just distributing a .zip file.<BR>
I didn't get to the point of (offering to) altering $PATH, ensuring cl.exe/link.exe were available. But this perhaps be adequately handled by one line documentation telling people to run the "shortcut" that Visual C++ installs, that runs an appropriately setup command line (the platform SDK and DDK do the same).<BR>
<BR>
<BR>
I dread the "freeze" state approaching releases.<BR>
Please hopefully there is a "tag" or "branch" for the release, and I can continue working "my way" (churn too high for near release).<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>
<HR id=stopSpelling>
Date: Wed, 1 Apr 2009 19:05:16 -0400<BR>From: rcoleburn@scires.com<BR>To: m3devel@elegosoft.com<BR>Subject: [M3devel] new cm3 release (was: Help finding CM3 compiler for Linux?)<BR><BR>
<DIV>I agree about needing a new release.</DIV>
<DIV> </DIV>
<DIV>I suppose there is some value in maintaining a MINimal size binary distribution, but I think it would also nice to also provide a FULL distribution with everything pre-built. (Of course, this will eat up more space on elego machines.)</DIV>
<DIV> </DIV>
<DIV>I have ready access to Windows XP (32-bit and 64-bit) and Vista platforms. I would be glad to build and supply the distros for these platforms.</DIV>
<DIV> </DIV>
<DIV>Suggest we agree upon a plan and a timeframe.</DIV>
<DIV>a. make a tag or something in CVS that marks what will comprise the official sources for the release</DIV>
<DIV>b. agree upon distribution format (platform naming conventions, compressed archive format for MIN and FULL variants)</DIV>
<DIV>c. get a list of who is going to supply distros for which platforms</DIV>
<DIV>d. establish procedure for how the distros will be uploaded to elego</DIV>
<DIV>e. set a date for contributors to have the distros uploaded</DIV>
<DIV>f. have someone put together the web page showing links to all the distros along with updated installation instructions</DIV>
<DIV> </DIV>
<DIV>One sticky issue in the past has been target location. If we unpack a distro and put it in a different place in the filesystem tree, we don't want it to break. I know that cminstall attempted to adjust the cm3.cfg file to deal with location differences. Do we need/want to build an installer program or script to deal with this issue, perhaps even adjusting cminstall will suffice? Or, do we give a set of instructions on which file(s) to edit when moving the install location?</DIV>
<DIV> </DIV>
<DIV>For Windows, I don't mind building an installer. Perhaps the installer could let you choose whether to install the MIN or the FULL version.</DIV>
<DIV> </DIV>
<DIV>Also, I think the Tinderbox has been great, but perhaps it can be improved. I know I would like to see testing for Windows platforms added. I have an XP computer I can pretty much dedicate to this task. The problem is that I tried with Olaf's help to get it working, but there were too many dependencies on unix-type shell/script environment, and trying to force fit into cygwin didn't work well for the native Win32 implementation. Thoughts?</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Mika Nystrom <mika@async.caltech.edu> 4/1/2009 6:25 PM >>><BR><BR>Actually I think that the thing that has caused me the most problems<BR>in the past is that the -min and the -src-all get out of sync, since<BR>the binary bootstrapping dists are often not distributed (for size<BR>reasons?) with full source archives from exactly the same date. So<BR>when you try to build src-all with the binary bootstrap, something<BR>goes wrong. It's the whole... ok I need a binary install (since<BR>it's a real compiler), but now I have to bootstrap everything. And<BR>then the bootstrap turns out not to be 100% compatible with the<BR>compiler sources, libraries, some little detail in m3tk, ...<BR><BR>Another way of saying this is "Isn't CM3 way overdue for a 'release'?"<BR><BR> Mika<BR></DIV></body>
</html>