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

[Jay K]

I'm on the fence wrt environment variables.
 
 
It is fairly rare for users to run executables by full path.
$PATH search and changing $PATH seems to be the way.
 
 
But what paths code tends to use, not sure.
It might also be blurry as "code" that runs stuff is initially users coding up their command lines in sh and then gradually formalizing things, and "formal" might or might not mean using full paths.
 
 
On Windows, there is no /usr/include.
You either set $INCLUDE and $LIB and/or you give paths to the compiler/linker on the command line. Or a mix.
 
 
Environment variables are The way to set something and have it be inherited by child processes, but not inherited by the rest of the system.
 
 
They lead to a process tree that works in one setup/configured temporary way.
But don't lead to an overall system that works a particular way, unless you set them somewhere with enough impact.
 
 
There is a larger problem in software wrt how to handle "settings".
There are environment variables. There are lots of text files in /etc. There is the Windows registry.
They all have pluses and minuses. Really, the Windows registry does have pluses.
The problem is related to just how many settings there are.
The more you need, the more general a solution is needed, and the less satisfactory it is bound to be.
 
 
It is far more complicated than most people realize.
"settings" are contextual. They can be per user, per machine, per user+machine combination, and more.
I'm sure people will claim "but such and such system solves it all", and maybe, but unlikely imho.
I mean, heck, per user but I have multiple machines.
How do I instantly change all my machines to use an orange desktop?
  Oh, well, there are "roaming profiles" on Windows and networked $HOME directories on Windows. Maybe. But I've basically never used them, so maybe they do solve it?
 
 
There are also settings that shouldn't be settings.
My terminal emulation usually doesn't quite work. (Amzazing how much does not work..). I find myself messing with $TERM but I should never have to. And still it doesn't work so maybe I don't have to, the problem is elsewhere..
 
 
 
 - 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
>