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 > [email protected] > https://dev.eclipse.org/mailman/listinfo/linuxtools-dev > _______________________________________________ linuxtools-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
