[M3devel] More MxConfig

[Jay K]

Supermin is just cm3 + config files.
And the config files we could/should m3bundle into cm3, leaving it to just be cm3.
Providing cm3cg is a nice optimization, but then, you know,
is the point to:
   build as much as possible  
  or build as little as possible? build nothing, just get "std" or all of Olaf's packages.
 
 
I would actually like to make cm3 dynamically linked, so supermin would
also include m3core, libm3, sysutils.
You could use ldd or whatever to discover.
 
 
Look at gcc for example -- it doesn't statically link to libc.
"Imagine if everyone statically linked the stuff they worked on
and wanted to easily backup" -- everything would be statically linked.
 
 
In terms of distribution purposes, well, I think providing just
one large .tar.gz archive per platform is ideal, and one .msi for Windows,
and a small number of .deb and .rpm files, like just x86 and AMD64.
 
 
Arguing about all the subsets has been very wasteful.
I don't want to add supermin and supermin+cm3cg to the debate.
 
 
Meanwhile what we are going to have is probably Olaf's package breakdown.
 
> "Moveable around" is probably good, but if a chunk of compiler
> infrastructure included in any program reading those variables is price
> - I think it's good point to reconsider goals and ways.

 
Given how broken it was before, I don't see changing it back.
I realize I've foisted "the compiler" on you, and there's a larger
issue as to the finding of cm3.cfg by the executable.
 
What about something like:
cm3 -print-variable INSTALL_ROOT
cm3 -print-variable HOST
 
or for that matter:
 
echo print(HOST)> fo o.quake 
 cm3 -eval foo.quake  
 
or
 echo print(HOST) | cm3 -eval foo.quake 
 
 
Better or worse?
 
Heck, you could just:
  type cm3 
 
and compute the rest yourself.
 
 
or you know the usual SearchPath function...
 
 
 
 - Jay



----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Mon, 3 Aug 2009 10:55:48 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] More MxConfig
>
> New auto-configuring cm3.cfg stuff is all ok. Great!
>
> I don't see importance of "moveable around" in that. Only "no need for
> cminstall and markers". "moveable around" is good when building from
> source using some kind of cm3-min.
>
> While at that, cm3-supermin with only cm3 binary and config files
> (probably cm3cg) would be supersmart feature. I am curently using
> cm3-min as a bootstraping device, and first thing I do is making libm3
> and m3core over from supplied source.
>
> "Moveable around" is probably good, but if a chunk of compiler
> infrastructure included in any program reading those variables is price
> - I think it's good point to reconsider goals and ways.
>
> On Mon, 2009-08-03 at 08:42 +0000, Jay K wrote:
>> Do you want to be able to move your cm3 install around, without
>> editing the config file?
>> You know, "be relocatable without any fixup code"?
>> That is the big question. That is what MxConfig buys.
>> These "variables" are computed, by running quake code.
>> They are in fact known at install time, unless you later move the
>> install around,
>> and require something (cminstall) to modify the config files at
>> install time.
>> If nobody cares about moving installs around without invalidating
>> their config file,
>> we could put it back to a bunch of string constants. And we'd have
>> to put back
>> the markers that trigger cminstall to replace stuff.
> --
> Dragiša Durić 
>