Re: RFC: toolenv - for dealing w/ tools' environments

On 24/2/03 17:16, Will Partain wrote:

> 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.

Hi Will,

Sorry to be just getting around to this.

I was wondering why you'd have the one-line shell scripts to invoke the real
executables via toolenv. Surely there would be a requirement to be able to
invoke the same executable in different environments depending on what tool
packages it is being used with?

I was thinking that users would need to "declare" what environment they need
and then just invoke the executables directly. Something like:

    % toolenv verisity-specman cadence-LDV
    % specview --special-option=on -c config1 mumble.spec

(I know nothing about what specview does ;-))

Where the 'toolenv' here would be a magic shell alias that invokes the real
toolenv and slurps the result into the environment (I hate explicit 'eval'
stuff). The PATH etc would then be setup as appropriate so that the user can
invoke specview directly and run the right one with the right environment
(this might be a script if necessary).

I guess I'm thinking along the lines of my old 'usepackage', but I never
allowed for the configurations to vary depending on what other packages were
requested or already in use.

    <http://www.onegoodidea.com/source.html>

Even though my environment tends to be much simpler these days, I still
can't live without usepackage - it's in use on my iBook. It can be fairly
easily configured to search the current directory (or the parent) for spec
files, allowing fairly simple per-project environments to be configured.

A proper understanding of how packages inter-relate and the ability to
invoke commands would be a cool addition to usepackage, but I rarely make
any non-bugfix changes anymore since there's only one person on the mailing
list and he's the debian package maintainer ;-)

Jonathan

-- 
jonathan hogg, one good idea ltd, 131 queen margaret dr., glasgow g20 8pd
http://www.onegoodidea.com/ tel:+44-(0)7976-614338 fax:+44-(0)7970-537451



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