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

[turnham@xxxxxxxxxx]

Hi Dave,

>Some questions on your write-up:
>
>It looks like the proposal is also meant to cover build.  If so, is the
>launch config the best place to put it?

Yes the Environment Support is meant be used in various places.  Sorry if I
wasn't clear.  I wasn't asking if the Environment Wizard should live with
the Launch Configurations (it shouldn't)...I was asking if the Environment
Selector widget should be something that comes with the Launch
Configurations.  The same widget would appear in various places including
our Project Build Property pages, and in our Command Launcher (which can
launch arbitrary commands locally or remotely).

>Are there other places that could use/reference a common environment (eg.
>the Java tooling)?

Yes, I suppose I should post to the platform-dev newsgroup.  I just wanted
to get an idea if something of this sort had been talked about in relation
to the Launch Configurations.

>The example you give of overriding multiple environment and the resulting
>composed PATH environment variable seems to be very PATH oriented.  Paths
>can have multiple entries so it makes sense to compose them.

I'm not quite sure what you mean by "compose" them other than simple
concatenation.  If you had the following Environments:
ENV1  PATH=/usr/bin:/usr/local/bin
ENV2  PATH=/opt/bin:/opt/share/bin

and then had ENV3 which was set up to override both ENV1 and ENV2, and
contained
PATH=${PATH}:/some/other/bin

I am proposing that the evaluated value would be:

PATH=/usr/bin:/usr/local/bin:/opt/bin:/opt/share/bin:/some/other/bin

Are you looking for something different?

>What about environment variables in the overridden environments that
cannot be
>composed in any natural fashion --e.g. locale or time zone?

Yes this could be an issue when multiple overrides are involved....so let's
say you have the following:

ENV1    LOCALE=en_US
ENV2    LOCALE=ja_JP

When a user creates another Enviroment that overrides these 2, the question
becomes what is LOCALE equal to?

In this case it appears obvious that we should simple make a choice since,
as you say, putting the 2 values together does not make sense.  But that
would imply the same mode of operation for all the path based Environment
Variables (PATH, LIBPATH, LD_LIBRARY_PATH, etc). So I see 2 ways around
this:

1. We look for a filename separator (/ or \) in Varaible values, and if we
find one, we assume that it is Path-Based and compose them.  If not we
default to just picking one of the possible values.  This is a pretty weak
solution since there are plenty of variables values that contain a PATH but
are not really intended to have multiple entries (HOME for example).

2. We add a way for users to specify which variable values can contain
multiple values.  This would simply be a check-box somewhere in the wizard
that was said something like "multi-valued".  This would allow us to know
how to deal with multiple variable values.

Thoughts?

Jeff.
============================
  Jeff Turnham
  Linux Application Development
  IBM Toronto Lab, D2-328
  (905) 413-4319
============================