[M3devel] CM3 RELENG: suggestion for distribution packages

[Jay]

  >  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

 

Here's a summary:

 

 - The config files used to each be
 independent, but /highly/ redundant.
 They had a lot of identical or nearly-and-could-be code.
 I factored a lot, so there is shared code.
 Worse -- besides the redundancy between the
 different platforms, every config file was duplicated
 twice in the tree with very minor differences.
 It was confusing and a maintenance problem.
 

 - The installer would write full paths
   to compiler/linker. That is one viable approach.

   If people really like that, we should factor it in somehow.
   What I do instead is just run leaf "gcc", "cl", etc.
   and depend on $PATH search.
   Also regarding paths to libraries, I found what
   they were on each of my system and assume they
   are pretty well standardized. If someone really
   has a custom layout, they will need to edit the files.
   If someone doesn't want the gcc that comes first
   in $PATH, they will either need to change $PATH
   or edit the file.


   At some point, you know, if someone wants something
   different, they can also edit the source to cm3 and rebuild it.
   If the config files can be made correct enough
   for enough people, you can consider these things
   in the same category.


   You know, you don't install all *.sh, *.pl, *.py code to /etc.

   You pick some "knobs". Not too many, not too few.
   There were generally more than necessary before I believe.
   But maybe I'm wrong here?

 

   On *BSD some things would not be in the default install, but

  there'd be a port/package, so where the port installed, I'd use that path.

  This is grayer, since you can also install things yourself and the

  default from "upstream" might be different.

 

  On Mac OSX I would generally get the third party package and

  find its default.

 

  e.g. postgresql. 

 

  Something more is probably needed here, like file existance checks.


 - Full path to the cm3 install implemented via path() and walking
   from there. path() is the path of the quake config file
   that calls it. cm3.cfg knows it is next to the compiler, or maybe
   in a sibling directory to it, that the install root is path()/..


 - I have some semantic changes such as use of $ORIGIN,

 use of hardlinks instead of symlinks (so $ORIGIN works better),
 updating NT386 for use with current and older tools, to

 statically link in shared data (the set/hand stuff).

 


 - I introduced an optional toplevel cm3.cfg that
   probes around for the "real" config file, such
   as to use the current one in the source tree,
   so I don't have to keep copying it around, or
   or to use one based on an an environment variable
   specifying target platform. Probing around
   in the source tree is not appropriate for
   a "release" version and that is taken into
   account. There is also probing around in the release
   directory. There is also probing for a backend,
   again for cross build purposes. The exact probed
   paths and their sequence is certainly up to debate.

 

 - In terms of compatibility, there are also runtime checks, so that

   older cm3cg isn't given an -m32 flag that is rejects, stuff like that.

   Also workarounds for bootstraping from a compiler with the old GC implementation.

 

  After this release I think we'll declare that you can only bootstrap from

   this release or newer and remove various compatibility hacks. Maybe.


 - Jay

 


Date: Thu, 28 May 2009 11:52:49 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com
Subject: Re: [M3devel] CM3 RELENG: suggestion for distribution packages


Of course, there are platforms that don't use etc, like Windows.
 
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.
 
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".
 
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?
 
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.
 
My 2 cents:  Whatever is decided, we need to document it, and make it widely known (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.
 
Regards,
Randy

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