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

[Darko Volaric]

Besides advantages/disadvantages, can we consider user requirements?

People who do native Mac development would need to (regularly) build  
for 3 targets: I386_DARWIN, AMD64_DARWIN and PPC_DARWIN which requires  
three different compilers, different libraries and different cfg  
files. In my mind the simplest solution would be to look next to the  
binary first as it does now, unless some new arrangement selects cfg  
files by the compiler target arch.

Do we need to break the existing system and compatibility with  
existing installations and processes and if so, what is the payoff,  
besides simplification?


On 03/08/2009, at 11:15 PM, Olaf Wagner wrote:

> Quoting Darko Volaric <lists at darko.org>:
>
>> 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"?
>
> The compiler searches in a list of locations and takes the first
> one found, as is the convention when doing path searches. AFAIK
> /etc is currently the last option at all.
>
> Perhaps we should try to gather the facts and write up a pro/cons
> list for different options.
>
> In all previous releases cm3 used the following strategy to find
> its configuration:
>
> "traditional"
>
> (1) ./cm3.cfg
> (2) src/cm3.cfg
> (3) ../src/cm3.cfg
> (4) $M3CONFIG
> (5) Pathname.Prefix( Params.Get( 0 ))
> (6) for p in $PATH: try p/cm3.cfg
> (7) give up...
>
> Because people were complaining that it wasn't possible to adhere
> to common system conventions with CM3 installation packages,
> I extended this strategy like this:
>
> "extended"
>
> (1)..(6) same as above
> (7) /usr/local/cm3/etc/cm3.cfg
> (8) /usr/cm3/etc/cm3.cfg
> (9) /cm3/etc/cm3.cfg
> (10) /usr/contrib/etc/cm3.cfg
> (11) /usr/local/etc/cm3.cfg
> (12) /usr/etc/cm3.cfg
> (13) /opt/etc/cm3.cfg
> (14) /sw/etc/cm3.cfg
> (15) /etc/cm3.cfg
>
> I do insist neither on this list nor the order or the locations
> themselves. On the other hand I do not see much harm in an extension
> like this, allowing a certain degree of freedom for those preparing
> system dependent installation packages.
>
> Recently Jay suggested to radically change the strategy:
>
> "reduced"
>
> (1) $M3CONFIG
> (2) Pathname.Prefix( Params.Get( 0 ))
> (3) give up
>
> We should now consider the advantages and disadvantages of each
> of the proposals. The following lists are not complete; I just make
> a start and others please extend as they see fit:
>
> "traditional"
>
> advantages:
>  o seems to have worked OK with cm3, cm3ide etc. until now --
>    never change a running system (not very convincing ;-)
>
> disadvantages:
>  o system dependent non-standard values only possible via environment
>    settings M3CONFIG or PATH
>  o not simple and easy to remember
>
> "extended"
>
> advantages:
>  o just an extension to existing strategy
>  o allows for several conventional standard locations for config files
>
> disadvantages:
>  o not simple and easy to remember, may be confusing
>
> "reduced"
>
> advantages:
>  o simple and easy to remember
>
> disadvantages:
>  o system dependent non-standard values only possible via environment
>    setting of M3CONFIG
>  o may be incompatible with certain use cases of cm3 and cm3ide (to
>    be investigated)
>
> There are also the general arguments saying that
>
>  "no (user) configuration of cm3 is needed at all" (really?)
>
> and
>
>  "that may be said of a lot of tools and services whose config files
>   live in /etc/ and may just be adapted by root"
>
>  "we should heed the standards and conventions of existing systems
>   in order to be used"
>
> That's of course just a start, I'm sure I have forgotten many good
> arguments. Let's try to keep to the facts as much as possible though.
>
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin,  
> Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23  
> 45 86 95
>   http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz:  
> Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> DE163214194
>