<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
"some builds" is builds using overrides -- "buildlocal".<BR>
You can often sleaze by by having a compatible already shipped libm3, but you aren't supposed to do that.<BR>
You are supposed to be able to make breaking changes to libm3 and keep them temporarily separate from your mainline in-use package store.<BR>
<BR>
I'm highly suspicious of the override mechanism, but this is how things are done throughout the tree and I'm not going to change it any time soon. This merely brings windowsResource inline with how everyone else does it.<BR>
<BR>
I understand there is a need for multiple package stores, so you can develop and experiment and break one, and then go right back to a working one, but I suspect alterate package store should be "shipped to other roots", not the unshipped output sitting in the source tree.<BR>
<BR>
"Fixing" this would allow more concurrent builds.<BR>
<BR>
Basically, you know, there are three sets of outputs:<BR>
temporary files that aren't going to be shipped -- .o files <BR>
files that aren't going to be shipped -- executables/.dll/.so -- in the same place as the .o files <BR>
the shipped files <BR>
<BR>
The first two sets are in the source tree, but I think should not be.<BR>
And then, if that is fixed, it might be ok to remove the second set and just ship things as they are built, right to the third set.<BR>
<BR>
You know..this is one of those ways in which Modula-3 was arguably ahead of its time, but the world has caught up, and possibly surpassed it.<BR>
<BR>
In particular, if you only look at a single package, Modula-3 has always kept the source tree clean, it has always and only supported putting the outputs outside the source tree. Good. These days, most packages outside of Modula-3 support either way (though some only work one way or the other, or are only tested one way or the other; good example is that gcc only really supports out-of-source builds). Where Modula-3 fails though is if you consider multiple packages. Then, in a real sense, the outputs are in the source tree. The analog outside the Modula-3 world is..tenuous..usually there is rarely automatic stitching together of multiple packages. In fact, even Modula-3 -- cm3 -- doesn't do that. But we have heavily used automation that does (scripts directory). The only analog I can think of in the non-Modula-3 world is how the gcc tree stitches together multiple packages, and keeps all the outputs outside the overall source tree, instead of only on a package by package basis.<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
Date: Wed, 31 Dec 2008 10:58:44 -0500<BR>From: rcoleburn@scires.com<BR>To: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] [M3commit] CVS Update: cm3<BR><BR><BR>
<DIV>Jay:</DIV>
<DIV> </DIV>
<DIV>I'm not sure why an m3overrides file is needed for "some builds".</DIV>
<DIV> </DIV>
<DIV>The WindowsResources package simply adds a template that allows folks on Windows platforms to include icons and other resources in their programs. This package shouldn't be needed for non-Windows platforms.</DIV>
<DIV> </DIV>
<DIV>Indeed, the template (winRes.tmpl) uses "if equal (OS_TYPE, "WIN32")" to bracket all of its activity, so it shouldn't do anything on non-Windows platforms.</DIV>
<DIV> </DIV>
<DIV>Perhaps, the same logic should be used in the m3makefile to prevent inclusion of the WindowsResource package on any platform other than Windows, but then that would probably force similar logic in all packages that import WindowsResources. I know that CM3IDE uses WindowsResources and, of course, I have a number of programs that use it.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay Krell <jkrell@elego.de> 12/31/2008 11:57 AM >>><BR>CVSROOT:/usr/cvs<BR>Changes by:jkrell@birch.08/12/31 11:57:14<BR><BR>Added files:<BR>cm3/m3-sys/windowsResources/src/: m3overrides <BR><BR>Log message:<BR>Add missing override to fix some builds.<BR><BR>I'm highly suspicious of all this "override" stuff.<BR>It clearly causes too much duplication and distribution of information.<BR>I shouldn't have to know the directory structure of my dependencies,<BR>and even if I do, I should be able to share that knowledge with their many<BR>other dependents. The "scripts" directory also figures this sort of stuff out automatically..<BR>Being able to have multiple package stores is well and good.<BR>I'm not sure they need to ever be used in an "unshipped" form, but instead just<BR>use alternate roots and create new empty roots as needed. ?<BR><BR><BR></DIV></body>
</html>