RFC: toolenv - for dealing w/ tools' environments

Folks, what follows isn't _really_ an Arusha Project thing,
except that you'll probably be able to get code for it
(assuming it pans out).

It's a note about a problem I've banged into over the past
few years, plus a proposed solution.  Any comments welcome.

Will

===

toolenv -- a solution to (EDA) tools' environment madness?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[A proposal -- comments most welcome.  EDA == Electronic
Design Automation]

The Problems
~~~~~~~~~~~~

Many tools -- notably EDA tools -- require one or more
environment variables to be set.  In the best case, you set
FOO_HOME (plus some license-finding thingie...) and then all
the tools in the Foo package Just Work (TM).

Problem #1: EDA tools tend to hook together... You invoke a
simulator (one or more environment variables...) and it
brings in some IP-library thing (one or more environment
variables...) and then later starts up a wave viewer (one
or more environment variables...) which might... (ad
infinitum).

Problem #2: In some cases, what pops out of such a scenario
is a new executable.  Typically, it will fail to run at all
unless one or more environment variables are set correctly.

[I would interested in hearing of similar cases from
_non_-EDA lands.]

The Standard Non-Solution
~~~~~~~~~~~~~~~~~~~~~~~~~

The standard solution is to ask individual users to set all
the required environment variables in their .profile,
.cshrc, etc., files.

If individual users have to do this in some ad-hoc way,
there lies madness.  (Yes, we've all seen it.)

If, instead, individual users 'source' some centrally-kept
files (e.g.  'source /our/share/tool-settings.csh'), then the
madness is gone but there are still "issues"...

* A single set of environment settings may not work across
  all necessary platforms (fixable, but painful)

* A single set of environment settings does not satisfy the
  need (of a project?) to work with a _specific_ combination
  of tools (and no others).

  (It's worse than that, really: in EDA land, it is entirely
  possible that one part of a project _requires_ one version
  of a tool, and another part _requires_ another version.  Yurk.)

* Part of the specification of what makes a project work is
  hidden, off in /our/share/tool-settings.csh (or equiv.)

* Because something like /our/share/tool-settings.csh is a
  crucial and delicate resource, it is easy to become
  reluctant to fix it, and then people start making "little
  workarounds" of their own...  (Madness returns.)

The Non-Standard Non-Solution (Arusha Project)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

An Arusha-Project-supplied "solution" to the problems
outlined above has been to "wrap" every interesting
executable in a shell script that sets its environment
correctly.  These wrapper scripts are created automagically
at tool-install time.

So, for example, when you type 'specman', what really runs
is:

1. A script that decides what *version* of Specman you want
   (uh, that's nothing to do w/ the problems outlined
   here... :-); which then invokes...

2. A _second_ script that sets up the environment correctly
   and then fires up the "real" specman executable.

This is A-OK for the "set one-tool-specific environment
variables and go" case.

It also wins big on the "user environment never needs to
know/change" front.

It is mediocre at best for the "set several-tools-specific
environment variables and go" case.

It fails for the "I am running a very specific set of
versions of tools" case.

It is utterly useless for the "a random executable has just
been created and needs a nice environment to run in" case.

A proposed solution
~~~~~~~~~~~~~~~~~~~

Let's start from a pretty general case, and then "simplify"
from there...  To run an executable 'foo' in an environment
that "makes sense" for tool packages 'wibble', 'wobble', and
'wubble', you would run

   toolenv wibble,wobble,wubble foo [foo-arguments]

For each of the EDA packages (wibble, wobble, wubble), toolenv
would:

1. Determine the version of each that is in play;

2. For the right version of each tool, invoke a Known Script
   that says "this is what I need in the environment"

3. Combine the environment information (e.g. removing
   duplicate entries from PATHs)

4. Optional: call another Known Script for each tool,
   essentially saying "This is the combined environment I'm
   about to use -- if you don't like it, say so now."

5. Invoke the real 'foo' binary (with foo-arguments) in the
   constructed, combined environment.

Now, obviously, we would not expect users to type 'toolenv
verisity-specman,cadence-LDV specview' instead of just
'specview'.  Instead, the 'specview' in their PATH will be a
one-line shell script that invokes toolenv as shown.

'toolenv' might also have flags that let it set up
environment and nothing else.  So, for example, to get a
sane (but imprecise) EDA environment into users' worlds,
their .profiles might include

   eval `toolenv --gen-env`

Comments
~~~~~~~~

It's not quite to the Just Works(TM) level, but not far
off.

-- end


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf