[MP-d] Alternative to `SK_HOME'

[Stefan M. <me...@df...>]

-----BEGIN PGP SIGNED MESSAGE-----

Hi!

I'm wondering about a good alernative to `SK_HOME'. The immediate
answer is probably `MP_HOME' but there is one drawback: If you have
more than one instantiation of Multiplatform - say SmartKom and Comic
- - you have to switch an environment variable to point to the right
directory. To me this sounds like a bad idea because this is a rather
error-prone solution (as all those know who had to work with two
different SmartKom system trees at one time).

We talked about this problems in the system group some weeks ago but
had no convincing idea.

Do you have an idea how to deal with this problem? Because `SK_HOME'
is at the very base of Multiplatform I think we need a robust solution
here.

Hmm... while I'm at it I can try to ramble a bit about the problem.

What is the real problem anyway? I'd say it can be described like
this: There are a number of different operations you want to execute
in a certain environment - namely `make' or running the Multiplatform
based system. Until now this environment was defined by the value of
the environment variable `SK_HOME'. The value of this environment
variable pointed to the system tree which held all the definitions and
resources those operations could possibly want. So `SK_HOME' worked as
a pointer to a rich structure.

The advantage - and drawback - of an environment variable is that it
is a process global variable you don't need to care about. Once set it
is available without needing further action. In this case it acts even
as a global constant.

This was ok as long as there was only one software system which could
be a possible target. A constant is nice for this type of problems.
But as I noted above even then it was a pain to work with two slightly
different system trees - say a current and an older version.

Hmm... So if this global variable / constant is a problem now this
pointer should become a parameter to the operations mentioned above in
some way then. The problem is: Where should the parameter be set and
where should it be stored so it can be retrieved as easy as an
environment variable?

Also we need to know which operations are actually affected by
`SK_HOME'. Of course running a Multiplatform based system is strongly
affected by `SK_HOME'. The other main operation which comes to mind is
running `make'. Are there any more? Ah - debugging is an additional
case. Some of the debugging tools need to run in the (correct)
Multiplatform environment. Anything else?

For running the system the solution is pretty simple: Give it the
value of `SK_HOME' as a parameter instead of using an environment
variable. For their convenience people can create aliases then and it
is clear whether they run `SmartKom' or `Comic'. The same is true for
the debugging phase. Many of the debug tools needed to be run by
`SmartKom' anyway so it is just straightforward to put the parameter
there.

`SmartKom' - or `Multiplatform' then - can put this parameter to an
environment variable - say `MP_HOME' - and it is available to all
children then. I.e. for existing calling schemes there need not be
changed anything. No module need to get an additional option or
something. The value is constant for all sub-proceses while it is a
parameter for the one who runs it.

The situation is different, however, for the `make' operation. For
instance the `Makefile's refer to `SK_HOME' to find the MakeIncludes.
`SK_HOME' is used in many places to refer to the environment. `make'
can be given parameters using `SK_HOME=3D...'. This gives the pointer to
the rich environment. `make' could be started by `Multiplatform' just
as any other operation. This would have the advantage that this is a
uniform concept then applying to all types of operation: To execute an
operation related to a Multiplatform based system one need to start
things using the `Multiplatform' startup script. This script sets up
all the environment possibly necessary. It is given a pointer to the
root of the system tree by a parameter. If this parameter is optional
in simple cases - i.e. exactly one Multiplatform based system - one
could even set the environment variable her/himself and s/he's done.

In addition such a solution would be easy to implement because it
needs no changes in existing modules (beyond referring to `MP_HOME'
instead of `SK_HOME'). For the `SmartKom' / `Multiplatform' startup
script it is also a simple change: Just use one option to set the
environment variable instead of expecting it in the environment.

Hmm... the longer I think about it the more find it a good solution.
Where am I thinking wrong? Other comments?


						Gr=FC=DFe

						Stefan

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAgUBP3RJhgnTZgC3zSk5AQHZRgP/U2mk/7i+6bEtBLZ2wH1OQb5U7J+oGb8B
u2r4HNcKX2sNEv1/DlKa91KlGL932VeZmEUS5aPxMxFU32G679yE2B3u/gZ9TQd2
ZDuyx2eLLQZ7TxPPjWJ3RzFBYtlV+Y/PzH7Z+UBU/sSMOVDfXnmtrCFaaNTrdzJV
9q7nuopNtFs=3D
=3DcXxP
-----END PGP SIGNATURE-----