Re: [platform-debug-dev] Support for specifying Environment from Launch

[turnham@xxxxxxxxxx]

Hi Dave,

>The path example in the document requires an understanding of
>the use of that variable on a given platform in order to
>accomplish the override. I'd like to see this generalized.

I tend to think about the user experience in a different way.  I think that
a user who is getting into setting Environment Variables will understand
the use of that Environment Variable on the given platform (If they didn't
understand it, why would they be trying to override it?)

I'm thinking that the majority of users who are "sophisticated enough" to
edit Environment Variables already know how to do this from a shell or some
other way.  So why not make the experience inside Eclipse as familiar as
possible?  Coming up with a generic way of doing will only require every
user to learn a new method of overriding Environment Variables.

I think that on Linux (and other Unix variants) a user should be able to
override a Variable with the standard syntax $VARNAME, ${VARNAME}, etc.
And perhaps on Windows they can use %VARNAME%.  The real area of confusion
that I fully acknowledge is in the ambiguities that arise from overriding
multiple Environments.  I have had some valuable offline discussion with
Robert Weisz (on my team), and he has pointed out that the ambiguity
problems we had talked about in earlier posts can be removed by simply
respecting order of the overridden environments.

So take the following example:

ENV1
  PATH=/usr/bin
  DEBUG=1

ENV2
  PATH=/usr/share/bin:${PATH}
  DEBUG=2

ENV3
  PATH={PATH}:/opt/bin

Now let's say that Env3 is setup to inherit (new word in place of
"override") from ENV1 and ENV2.  In the design document I was trying to
somehow combine variables in a way that would make sense to the user.  But
a much simpler way of working is simply respect the order that the
Inherited Environments are specified, and ONLY override or compose
variables if the user has set it up that way.    So in this case, since
ENV3 inherits from ENV1 and then ENV2, we simply start with ENV1 and apply
the changes from ENV2 to get the intermediate Environment:

ENV 1+2
  PATH=/usr/share/bin:usr/bin
  DEBUG=2

Then we apply the changes from ENV3 to arrive at the final computed
environment:

ENV3 (Computed):
  PATH=/usr/share/bin:/usr/bin:opt/bin
  DEBUG=2

The crucial point here is that, if in ENV2 the user had left out the
${PATH} part, then the PATH variable in ENV 1+2 would have only been
/usr/share/bin.  We would not try to do any composing that the user did not
explicitly specify.  Similarly, notice that the DEBUG value (=1) from ENV1
is "lost" since the user did not override it in ENV2.

So the paradigm becomes a cumulative construction of an Environment based
on the order of the Inherited Environments.  I am currently updating the
design document to describe this process.

Thoughts?


============================
  Jeff Turnham
  Linux Application Development
  IBM Toronto Lab, D2-328
  (905) 413-4319
============================
----- Forwarded by Jeff Turnham/Toronto/IBM on 05/01/2002 10:48 AM -----
                                                                                                                               
                    Dave_Dykstal@xxxxxxx                                                                                       
                    Sent by:                         To:     platform-debug-dev@xxxxxxxxxxx                                    
                    platform-debug-dev-admin@e       cc:                                                                       
                    clipse.org                       Subject:     Re: [platform-debug-dev] Support for specifying Environment  
                                                      from Launch Configurations...                                            
                                                                                                                               
                    05/01/2002 09:45 AM                                                                                        
                    Please respond to                                                                                          
                    platform-debug-dev                                                                                         
                                                                                                                               
                                                                                                                               




Darin's breakdown of the function seems to have the right feel, even if a
location in the debug component might not be the right place.  Slightly
modified:

(1) A way to define/persist environments by name (*.core)
(2) A way to manipulate environments by the user (*.ui)
(3) A re-useable widget/page choosing/editing environments (*.ui)
and additionally:
(4) A means for expressing this environment at the time of use (e.g.,
build, run, ...)

I'm not sure how (1) is any different from the ways we already have for
storing name/value pairs (.properties files, persistent resource
properties, dialog properties, ...)?  Is it possible to reuse one of these
mechanisms?  It seems to me that the real value here is in the values
editor (2) and the scheme that pushes these values into the environment (3
& 4).

 Secondly, while this seems to be a natural fit for C on Unix/Windows, it
feels a wee bit forced for Java, and maybe not relevant at all for other
build and runtime environments -- e.g. COBOL on CICS (if this even makes
sense).  Any UI for launching or building probably has to take this into
account.

Third, I'm uneasy about the rules Jeff has proposed for combining
environments and overriding values.  I don't see a general mechanism there
yet.  The path example in the document requires an understanding of the use
of that variable on a given platform in order to accomplish the override.
I'd like to see this generalized.

-- Dave

_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev