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

[Olaf Wagner]

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