[M3devel] Multiple CM3_ROOTs

[Jay]

I didn't change how the compiler "starts", how it finds
the first config file. Config files can go off and include
others.
 
 
The below sounds slightly wrong.
 
 
I believe the M3CONFIG environment variable is checked
before the cm3.cfg file "next to" cm3 is used.
 
 
What I do is my cm3.cfg "next to" cm3 then goes and looks
for the "real" config file.
 
 
It is guided by
 - knowing where the source tree is, via the environment
   variable CM3_ROOT
 - knowing the host, via the HOST variable that I added to cm3 
 - if HOST isn't defined, it generally fails, except on NT
   it can use the OS environment variable.
 
 
CM3_INSTALL or INSTALLROOT is the root of the cm3 installation.
CM3_ROOT or ROOT is the root of the cm3 source tree.
I don't find these names ideal, but I also am not super keen on changing them.
Clearer and more consistent would be CM3_INSTALL_ROOT and CM3_SOURCE_ROOT.
 
Within quake are available variables without the leading "CM3_".
Environment variables with leading "CM3_" I think are the way to go.
And that is /generally/ how it works, but not necessarily exactly.
 
Also, my cm3.cfg sets INSTALLROOT based on its own location.
 
 
To learn how to ship to another root...
My make-dist.py accomplishes this.
I think the way it works though is it copies cm3 out to a new location
and runs it from there. And the cm3.cfg.
INSTALLROOT or CM3_INSTALL is therefore the location of wherever cm3 is copied
to and run from.
 
 
Personally I think the system is somewhat misdesigned.
Regarding link output and shipped output, there should just be one place.
The only point in a two step link and ship/install is if you are
installing over a live system.
 
 
A simpler better approach is to always use a new or staging area
for the link output, and if you are happy with it, you merely
do a recursive copy on top of your live system.
Or, you change PATH to point to the new cm3 and adopt it as your new system.
This also addresses the problem that cm3 can't ship itself.
 
This also could be part of giving an alternate location for the "intermediate"
outputs that never shipped -- the .obj file.
They should not litter the source tree.
 
 
You know, on a package basis, Modula-3 is/was progressive in that
not only does it support "out of source" builds, but it only supports them.
And you can cons up arbitrary new intermediate locations on demand
by changing BUILD_DIR. Though sometimes assumptions creep in that
BUILD_DIR == TARGET.
 
However, if you consider multiple packages, then the intermediate outputs
actually are in the source tree.
 
There aren't many very visible analogs in the world.
However one is how gcc builds. It ties together multiple packages (optionally)
and all the outputs go outside of the entire source tree.
 
 - Jay


________________________________
> Date: Sat, 17 Jan 2009 20:50:16 -0800
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; eiserlohpp at yahoo.com
> Subject: Re: [M3devel] Multiple CM3_ROOTs
>
> Hi Peter:
> what I learned is that the cm3 compiler finds it's config file in the same directory of the cm3 compiler executable, otherwise it reports an error (about it).
> I know from cm3 -? that:
> from http://www.opencm3.net/doc/help/cm3/cm3-quickref.html
> environment variables:
>
> M3CONFIG platform dependent configuration file to use (cm3.cfg)
> used if no suitable file is found in the local package
>
> However I don't how can be used the compiler to ship and compile according the abstracted config files made by Jay specially in the NT386 and derived platforms (I guess would be nice to set that in the command itself like select to alternative not common configurations of graphic libs or back ends, etc, ...) with the same libm3 and m3core.
>
> Thanks in advance
> --- El sáb, 17/1/09, Peter Eiserloh
> escribió:
> De: Peter Eiserloh
> Asunto: [M3devel] Multiple CM3_ROOTs
> Para: m3devel at elegosoft.com
> Fecha: sábado, 17 enero, 2009 10:09
>
>
> Hi Tony and Gang,
>
> The hypothetical scenario is a system providing multiple
> user accounts. The sysadmin will install a released
> version of CM3, not a daily snapshot. Any user should be
> able to install a daily snapshot, and old one, or a custom
> version, for their particular use. This would go within
> a directory of their choosing (within their personal HOME).
>
> These users, may have many customized versions of libm3
> (and m3core), and hence many installations of an M3
> compiler.
>
> A git repository has already been imported from the main
> CVS repository at elego. Any user (at the moment
> thats
> just me) may create any number of branches and play with
> the code.
>
> How can I ship to a different CM3_ROOT, than the one that
> built it?
>
> When using a different CM3_ROOT than the standard one, the
> user would obviously have to set their PATH and CM3
> environment variables appropriately. How does the cm3
> compiler frontend know the path to its config file?
> Does it walk argv[0] up the directory chain, and use the
> PATH to find itself, or is the path build-in? Does it use
> the environment variable CM3 if found?
>
>
> +--------------------------------------------------------+
> | Peter P. Eiserloh |
> +--------------------------------------------------------+
>
>
>
>
>