[M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig

[Jay K]

I have to admit there is a mix of "clearly almost always correct, maybe really always" and "perhaps user editable code" in there.
 
I have hoped for no user editing but can't claim I got there, due to the library issues as you say, and maybe even -gstabs vs. -gstabs+ vs. -g, etc. -- heck maybe user wants slightly smaller binaries and doesn't mind slight loss of debugging, and doesn't want to strip afterward.
 
I did try to find "fairly canonical" places for libraries, such as wherever the platform package system installs things, but ultimately you can build yourself and get /usr/local instead of /usr/pkg, etc.
 
A possible solution is for the cm3.cfg file itself to probe, "at certain well defined points" for "certain well defined data", as well as leaving things not readonly.
 
 
For example at the very end it might probe for $HOME/etc/cm3.cfg and /etc/cm3.cfg and include them if they exist, or just the first.
 
 
I also don't want to get into the business of merging these files on user machines, either automatically or making people do it. I guess we are in the second situation now however.
 
 
A partial approach is to move more of the code into cm3, perhaps merely as Quake snippets, but that is perhaps overkill.
 
 
 - Jay


----------------------------------------
> From: lists at darko.org
> To: hendrik at topoi.pooq.com
> Date: Mon, 3 Aug 2009 23:59:43 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] HEADS UP: cm3.cfg locations, was: Re: problems with cm3.cfg and MxConfig
>
> The cfg files contain library lists which I change all the time. I
> understand there is a lot of build scripting in there too, but I
> ignore that and assume it's correct and see it only as a user config
> file. Maybe the "executable" bits need to moved elsewhere?
>
> Environment variables are pretty loathsome in my opinion. This is a
> bit of creeping unixism, but not everyone likes unix.
>
>
> On 03/08/2009, at 11:29 PM, hendrik at topoi.pooq.com wrote:
>
>> On Mon, Aug 03, 2009 at 08:59:26PM +0200, Darko Volaric wrote:
>>> Putting it in /etc would mean that having different active versions
>>> of
>>> compiler would e a pain, which is useful when developing, debugging
>>> or
>>> trying out new versions of the compiler and when compilers are not
>>> self hosted, which will be the case for ARM_DARWIN.
>>>
>>> What's the benefit of having it /etc other than being "standard"?
>>
>> Things in /etc/ are things that a system administrator might want to
>> tweak. At least that was the idea originally. These options we're
>> talking about seem somewhat different, in that they are tightly bound
>> with the software itself. I say they are more like executable code
>> than
>> like configuration files. If a Debian user were to install cm3.deb,
>> they had damn well point to the place the package put the compiler and
>> friends. I don't see the being usefully modified at all on a user's
>> machine..
>>
>> So, I'd say, look in /etc if some architecture policeman forces it;
>> otherwise treat the so-called configuration as if it were part of the
>> executable, in .../cm3/... .
>>
>> The environment variables are another good place to look, because that
>> makes it easy to experiment with multiple systems on one machine.
>>
>> -- hendrik
>