[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [linuxtools-dev] Changing the PATH for execution of linuxtools commands
|
On 09/30/2011 04:36 PM, Marc Khouzam wrote:
-----Original Message-----
From: Andrew Overholt [mailto:overholt@xxxxxxxxxx]
Sent: Friday, September 30, 2011 3:23 PM
To: Marc Khouzam
Cc: 'Linux Tools developer discussions'
Subject: Re: [linuxtools-dev] Changing the PATH for execution
of linuxtools commands
* Marc Khouzam<marc.khouzam@xxxxxxxxxxxx> [2011-09-30 15:10]:
-----Original Message-----
From: linuxtools-dev-bounces@xxxxxxxxxxx
[mailto:linuxtools-dev-bounces@xxxxxxxxxxx] On Behalf Of
Andrew Overholt
Sent: Friday, September 30, 2011 3:03 PM
To: Linux Tools developer discussions
Subject: Re: [linuxtools-dev] Changing the PATH for execution
of linuxtools commands
* Marc Khouzam<marc.khouzam@xxxxxxxxxxxx> [2011-09-30 14:44]:
[...] we have a UI box in the launch configuration dialog that
defaults to 'gdb' but that the user can change to the location
she needs e.g., /home/user/bin/myOlderGDB
I'm curious to know if this is something you considered?
I'm not particularly involved in this PATH effort so take
my comments
with a grain of salt but I personally dislike this type
of unnecessary
UI cruft. I would much prefer to support this case of vendor
tool SDKs
through an extension point or some other non-UI mechanism
if possible.
The first approach we were working was adding that to the Valgrind
Launch Configuration Dialog, but we avoided that after talking to Overholt.
After a long discussion with Jeff (you can read most part of it at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=353056) we decided to
create a common way of running commands in linuxtools and use a project
property prepended to system environment path to change the location of
the command we need to run. And that's the patch.
If you think that adding a property page to the project is not a good
for most of users it is possible to remove the dependencies in the ui
package and this page will only be added if the user install it
manually. But I think that it won't hurt the ui to have it and some
users may want to have different versions of some tools as we have here.
Yes, for vendor it makes sense to hide it under the hood,
but I believe
this issue was a user problem, where the user herself
wanted to choose
different versions at different times.
Is this that common?
We have an eclipse based product that runs in systems that have several
versions of some tools installed at the same time. And we need a way of
selecting which tool will be used for each project. That's why we
started that discussion. So that's a real use case :)
I'll let Otavio or Corey answer this one, as they brought up the issue.
I can see how it would be for gdb where there is
lots of progress and people have multiple versions installed. But for
relatively standard tools where the plugin integration isn't changing
too much, I'd rather take minimalist approach. The Eclipse
preferences situation is out of hand and so is the CDT project settings UI (IMHO).
Yes, I have to agree :-(
I just thought a project preference may be a bit obscure.
But I was asking out of curiousity more than anything else.
Marc
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
