[M3devel] [M3commit] CVS Update: cm3

Randy Coleburn rcoleburn at scires.com
Wed Dec 31 21:39:54 CET 2008


Jay:
 
I was just trying to explain a bit about the history of and reason for the windowsResources package.
 
As for m3overrides, I rarely use it anymore.  At one point in time, we had a large project going on and the engineers used m3overrides for local testing before shipping to the main repository.  That way, we avoided committing something that was obviously broken and causing other engineers to have downtime.  I also seem to recall devising a neat way to use m3overrides to build against stubs and to create test editions of a module.  Alas, it's been a long time since I've managed a project with many Modula-3 engineers working concurrently.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 12/31/2008 1:44 PM >>>
"some builds" is builds using overrides -- "buildlocal".
You can often sleaze by by having a compatible already shipped libm3, but you aren't supposed to do that.
You are supposed to be able to make breaking changes to libm3 and keep them temporarily separate from your mainline in-use package store.
 
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.
 
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.
 
"Fixing" this would allow more concurrent builds.
 
Basically, you know, there are three sets of outputs:
  temporary files that aren't going to be shipped -- .o files 
  files that aren't going to be shipped -- executables/.dll/.so -- in the same place as the .o files 
  the shipped files 
 
The first two sets are in the source tree, but I think should not be.
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.
 
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.
 
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.
 
 - Jay



Date: Wed, 31 Dec 2008 10:58:44 -0500
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] [M3commit] CVS Update: cm3


Jay:
 
I'm not sure why an m3overrides file is needed for "some builds".
 
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.
 
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.
 
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.
 
Regards,
Randy

>>> Jay Krell <jkrell at elego.de> 12/31/2008 11:57 AM >>>
CVSROOT:/usr/cvs
Changes by:jkrell at birch.08/12/31 11:57:14

Added files:
cm3/m3-sys/windowsResources/src/: m3overrides 

Log message:
Add missing override to fix some builds.

I'm highly suspicious of all this "override" stuff.
It clearly causes too much duplication and distribution of information.
I shouldn't have to know the directory structure of my dependencies,
and even if I do, I should be able to share that knowledge with their many
other dependents. The "scripts" directory also figures this sort of stuff out automatically..
Being able to have multiple package stores is well and good.
I'm not sure they need to ever be used in an "unshipped" form, but instead just
use alternate roots and create new empty roots as needed. ?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20081231/e02aef8b/attachment-0002.html>


More information about the M3devel mailing list