[M3devel] CM3 RELENG: suggestion for distribution packages

[jay.krell at cornell.edu]

I missed a question: we only currently support Microsoft Visual C++  
for NT386, pretty much any version, and gcc for MIN/GNU but consider  
those maybe not well supported by me. I am aware of a number of  
alternatives such as OpenWatcom, Digital Mars, Borland, lcc, old  
Symantec, old Metrowerks, I have used them all some but nothing real  
yet and not near top of my list by far.

  - Jay (phone)

On May 28, 2009, at 6:17 PM, Jay <jay.krell at cornell.edu> wrote:

>   >  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
>