Re: [linuxtools-dev] The location of Linux Tools Project executables

[Daniel HB <danielhb@xxxxxxxxxx>]

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
>