[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [linuxtools-dev] The location of Linux Tools Project executables
|
Hey Corey!
I think it's a good idea but I don't think, unfortunately, that is
simple to implement in the case of the Oprofile plugin. It uses a script
to add an entry in the sudoers (Suse) or add a security wrapper for
consolehelper (RHEL). After that it executes the tool using a symbolic
link located inside its own plugin dir (under /scripts/natives/linux dir
or something like that). Both procedures require a path to the oprofile
binary and root access.
To make it work properly, OProfile_Root_Path must contain a symbolic
link created by the install script of Oprofile. That's quite a strong
assumption IMO.
Apart from this Oprofile setup I think we can make all the others work.
However I'm not certain about adding such such customization plug-in as
a prerequisite for Linuxtools install. If we could make it optional,
ensuring that the Linuxtools plug-ins would work as is without this
customization, the better.
- daniel
On Mon, 2011-06-20 at 18:23 -0700, Corey Ashford wrote:
> Hi Folks,
>
> We have an interesting challenge with the Linux Tools Project plug-ins,
> and that is being able to determine where each of the linux tool
> executables are. I think for most users of the plug-ins, they can
> assume that all of the tools are on their search path, for example
> /usr/bin/opcontrol.
>
> However, in our SDK, we may have multiple versions of toolchains, and
> ideally, we'd like to be able to associate a set of tool paths on a
> per-project basis. As a concrete example, I want project A to use
> opcontrol from /usr/bin, project B to use /opt/at4.0/bin/opcontrol, and
> project C to use /opt/at5.0/bin/opcontrol.
>
> I'm fairly certain that there's no existing mechanism in the Linux Tools
> Projects plugins determining the location of the tools. They are just
> assumed to be on $PATH somewhere.
>
> As a solution, I'd like to suggest that each tool look into the
> project's persistent properties for a root path specific to it. For
> example, we can have these persistent properties:
>
> OProfile_Root_Path
> Valgrind_Root_Path
> SystemTap_Root_Path
> Autoconfig_Root_Path
> etc.
>
> Each tool would look for its persistent *_Root_Path property, and if it
> doesn't find one, it would work as it does today, otherwise, it would
> prepend the *_Root_Path property value onto the executable's name and
> invoke that instead of relying on $PATH.
>
> I'm not certain if it's possible, but one of the prerequisites for
> installing any of the Linux Tools Project plug-ins would be a plug-in
> that would add another entry in the project properties under "C/C++
> Build", and would allow setting each of these root paths by hand
> (project wizards could also set them as desired by the specific toolchain).
>
> Any thoughts? Is there a better way to go?
>
> - Corey
> _______________________________________________
> linuxtools-dev mailing list
> linuxtools-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
>