<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
> I know Jay has been making great strides with the config files, but<BR>
> I don't believe everyone is "clued-into" what has been done and the rationale behind it<BR>
<BR>
Here's a summary:<BR>
<BR>
- The config files used to each be<BR> independent, but /highly/ redundant.<BR> They had a lot of identical or nearly-and-could-be code.<BR> I factored a lot, so there is shared code.<BR> Worse -- besides the redundancy between the<BR> different platforms, every config file was duplicated<BR> twice in the tree with very minor differences.<BR> It was confusing and a maintenance problem.<BR> <BR>
- The installer would write full paths<BR> to compiler/linker. That is one viable approach.<BR>
If people really like that, we should factor it in somehow.<BR> What I do instead is just run leaf "gcc", "cl", etc.<BR> and depend on $PATH search.<BR> Also regarding paths to libraries, I found what<BR> they were on each of my system and assume they<BR> are pretty well standardized. If someone really<BR> has a custom layout, they will need to edit the files.<BR> If someone doesn't want the gcc that comes first<BR> in $PATH, they will either need to change $PATH<BR> or edit the file.<BR>
<BR> At some point, you know, if someone wants something<BR> different, they can also edit the source to cm3 and rebuild it.<BR> If the config files can be made correct enough<BR> for enough people, you can consider these things<BR> in the same category.<BR>
<BR> You know, you don't install all *.sh, *.pl, *.py code to /etc.<BR>
You pick some "knobs". Not too many, not too few.<BR> There were generally more than necessary before I believe.<BR> But maybe I'm wrong here?<BR>
<BR>
On *BSD some things would not be in the default install, but<BR>
there'd be a port/package, so where the port installed, I'd use that path.<BR>
This is grayer, since you can also install things yourself and the<BR>
default from "upstream" might be different.<BR>
<BR>
On Mac OSX I would generally get the third party package and<BR>
find its default.<BR>
<BR>
e.g. postgresql. <BR>
<BR>
Something more is probably needed here, like file existance checks.<BR>
<BR> - Full path to the cm3 install implemented via path() and walking<BR> from there. path() is the path of the quake config file<BR> that calls it. cm3.cfg knows it is next to the compiler, or maybe<BR> in a sibling directory to it, that the install root is path()/..<BR>
<BR> - I have some semantic changes such as use of $ORIGIN,<BR>
use of hardlinks instead of symlinks (so $ORIGIN works better),<BR> updating NT386 for use with current and older tools, to<BR>
statically link in shared data (the set/hand stuff).<BR>
<BR>
<BR> - I introduced an optional toplevel cm3.cfg that<BR> probes around for the "real" config file, such<BR> as to use the current one in the source tree,<BR> so I don't have to keep copying it around, or<BR> or to use one based on an an environment variable<BR> specifying target platform. Probing around<BR> in the source tree is not appropriate for<BR> a "release" version and that is taken into<BR> account. There is also probing around in the release<BR> directory. There is also probing for a backend,<BR> again for cross build purposes. The exact probed<BR> paths and their sequence is certainly up to debate.<BR>
<BR>
- In terms of compatibility, there are also runtime checks, so that<BR>
older cm3cg isn't given an -m32 flag that is rejects, stuff like that.<BR>
Also workarounds for bootstraping from a compiler with the old GC implementation.<BR>
<BR>
After this release I think we'll declare that you can only bootstrap from<BR>
this release or newer and remove various compatibility hacks. Maybe.<BR><BR>
- Jay<BR><BR> <BR>
<HR id=stopSpelling>
Date: Thu, 28 May 2009 11:52:49 -0400<BR>From: rcoleburn@scires.com<BR>To: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] CM3 RELENG: suggestion for distribution packages<BR><BR>
<DIV>Of course, there are platforms that don't use etc, like Windows.</DIV>
<DIV> </DIV>
<DIV>I'm ok with whatever approach makes sense for the given platforms wrt configuration files; however, I will point out that for those of us who've been using Modula-3 for a long time, that we are used to having to mess around with the config files to get things to work correctly. I'm all for simplifying things and would love NOT to HAVE to mess with the config files, as long as whatever approach is taken allows for adequate flexibility in adapting to particular installation requirements.</DIV>
<DIV> </DIV>
<DIV>On a Windows platform, most programs are stored in %ProgramFiles%, typically "C:\Program Files", but CM3 is more than a program, it is a repository of packages etc. Typically, ordinary users don't get write privileges to %ProgramFiles%. So, I've always put my installation in "C:\cm3", but then some folks might have multiple drives and partitions and want to put it somewhere else. Indeed, I once used "D:\cm3".</DIV>
<DIV> </DIV>
<DIV>Another thing that the config files had to be adapted for in the past was where to find the C compiler, libraries, and linker. Today, we have the free Microsoft Visual Studio tools, but there are other vendors of C compilers and linkers. Which of these will the config files support?</DIV>
<DIV> </DIV>
<DIV>Critical Mass also adapted the config file to tell "Reactor" where to find certain things. Of course, now we have CM3IDE as the replacement for Reactor and I've tried to adapt the code to deal with some of Jay's changes to the config files.</DIV>
<DIV> </DIV>
<DIV><STRONG><U>My 2 cents</U></STRONG>: Whatever is decided, we need to <U>document</U> it, and make it <U>widely known</U> (i.e., publicize it) so that us old timers understand whether we should or should not keep tweaking the config files. I know Jay has been making great strides with the config files, but I don't believe everyone is "clued-into" what has been done and the rationale behind it, hence the need for some publicized documentation. Then, we need to go back and revise old documentation, such as that with CM3IDE, to reflect the new reality. I can make doc changes, but I need to understand new content first.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR></DIV></body>
</html>