[M3devel] M3Config

Jay K jay.krell at cornell.edu
Fri Jul 31 03:30:04 CEST 2009


It was partly unsupportable and you can trivially replace it with MxConfig.
Please try that -- MxConfig. MxConfig.Get() I recall.
 
 
We can put back the supportable part if you insist, but the full paths either need to go, or the thing needs to be fixed up at install time, and the results not "relocatable" with repeating the "fix up". (You know, "relocatable" like how $ORIGIN enables, install anywhere, and no "fixup" required).
 
 
 - Jay



----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Fri, 31 Jul 2009 00:20:39 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] M3Config
>
> I have code reading data structure information from .M3WEB files.... And
> that code used M3Config for obvious things... Now when you killed it,
> how I am supposed (in portable way) to find these files? :)
>
> TIA,
> dd
>
> On Thu, 2009-07-16 at 20:36 +0000, Jay K wrote:
>> So..I was wondering..what were the original authors thinking?
>>
>> And there was that comment about the file containing the data upon
>> install.
>> Which seemed wrong to me.
>>
>> They were probably thinking of the way 3.6 was packaged and
>> distributed -- everyone built the system from source, upon building
>> m3build/m3ship from C and m3 from assembly.
>>
>> That isn't a bad model, but we probably want both.
>>
>> There are at least three times the paths can be computed/recorded:
>> 1) when you build libm3
>> 2) when you install libm3
>> #1 and #2 may or may not be close in time and have the same result.
>> 3) by parsing cm3.cfg as needed
>>
>> #2 is more efficient than #3 and matches the old code, but #3 is how I
>> left it, probably ok.
>>
>> - Jay
>>
> --
> Dragiša Durić 
>


More information about the M3devel mailing list