Re: [linuxtools-dev] Linuxtools unified launch

[danielhb@xxxxxxxxxx]

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 <jjohnstn@xxxxxxxxxx>
To:	Linux Tools developer discussions <linuxtools-dev@xxxxxxxxxxx>,
Date:	10/09/2012 05:08 PM
Subject:	Re: [linuxtools-dev] Linuxtools unified launch
Sent by:	linuxtools-dev-bounces@xxxxxxxxxxx

---

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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev