How to define which profile tool to use with this unified launch? Because right now linuxtools have Valgrind (and all the subtools), Oprofile, Perf ....
Maybe running all the available tools and providing all the results in a "Profile" perspective? Sorry to jump in the middle of the discussion ... I just feel that I am missing something here. Thanks, _____________________________________________________ Daniel Henrique Barboza Software Engineer - IBM Linux Technology Center Brazil From: Jeff Johnston <jjohn...@redhat.com> To: Linux Tools developer discussions <linuxtools-dev@eclipse.org>, Date: 10/09/2012 05:08 PM Subject: Re: [linuxtools-dev] Linuxtools unified launch Sent by: linuxtools-dev-boun...@eclipse.org On 10/09/2012 02:47 PM, Roland Grunberg wrote: >> Hi all, >> >> I saw a message from Jeff into CDT mailing list regarding unifying >> linuxtools launchers. If I understood correctly that unification is >> emphasized for local c/c+ although we now have remote capabilities in >> almost all plug-ins and, thus, I got a bit worried. > > I think the remote tools we have should still work. The goal of the > unification that was discussed is mainly so that we can inherit the > launch configuration attributes from a regular C/C++ launch, and > potentially have the CDT delegate the launching to our tools in certain > cases (eg. the user specifies they want profiling). > > Jeff could probably give a bit more detail on this. > The idea is that the launch short-cut should define the executable and how it is launched, not the profiling tool. From a grammatical point of view, it does not make sense to say: Profile as...-> Profile with Valgrind. Now, there is already a Local C/C++ Application short-cut used by the CDT which only specifies Run and Debug modes to the Eclipse Platform. The proposal is to extend the CDT's launch short-cut such that it will provide profiling support through our framework. Thus, a user will see one of the choices as: Profile as..-> Local C/C++ Application. This makes sense and as Roland has noted, the end-user benefits in that common settings such as Program Arguments and Environment Variables only need to be set once for all 3 modes: Run / Debug / Profile. Regarding remote support: there is nothing to prevent a special launch short-cut being created that is titled "Local C/C++ Application on Remote System" which defines our remote efforts thus far. If we were to do it, it would likely not support debugging. If we could convince the CDT to add it, it would use the same underlying mechanism to bind our profiling framework in their short-cut. The work of sharing the CDT Local C/C++ Application Launch short-cut is being proposed for Kepler and is only in the infant stages of discussion. I attended the Multicore-Debug call today and in fact got some positive feedback on the idea. I am opening a bug regarding this. >> Indeed, it seems a great refactoring that should improve usability a >> lot >> and I just would like to check negative impacts (if any) in the >> project >> that I work on. So my broaden doubt is: what is the plan for unified >> launch? > As mentioned, Kepler only. > There is a profiling unification we are planning for 1.2 which is > outlined here : > > http://wiki.eclipse.org/Linux_Tools_Project/Profiling/Unification > > All the plugins that will be contributing to it have been modified > to work, and this work is being done on the master branch. In most > cases the only change needed was done in the plugin.xml (with some > plugins needing the creation of a launcher). > > Hope this helps, > _______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
_______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
