Community
Participate
Working Groups
This enhancement proposes that the CDT Local C/C++ Application launch short-cut used for Run/Debug also add the Profile mode and that the CDT create an extension such that external providers (such as Linux Tools) can supply profiling tool support. The extension would specify a class to instantiate which would provide at least: a launch delegate and additional launch tabs to show in the Profile Configurations Dialog. The extension would identify what launch type id it supports to allow the CDT to locate an appropriate profiling provider when needed. Regarding the launch tabs, the additional profiling tabs could be disabled/omitted when in Run/Debug mode and likewise, the Debug settings tab could likewise be disabled/omitted when in Profile mode, but this is entirely optional. In the case where no matching profiling provider is found by the CDT, either a default launch tab could be presented which would indicate there are no profiling tools installed to use or the Run configuration could be presented as-is. Launching such a configuration would simply Run the executable as normal and present no additional output or reports. Background As of Juno SR1, the Linux Tools project which supplies a number of profiling tool plug-ins such as Valgrind, OProfile, Perf, Gprof, Gcov, and SystemTap provides launch short-cuts for the various tools. Each profiling launch short-cut creates a menu entry under Profile As... which doesn't really make grammatical sense (e.g. Profile as..-> Profile with Valgrind) whereas the CDT provides a shared Run/Debug launch short-cut for a Local C/C++ Application. This does make sense: e.g. Run as...-> Local C/C++ Application. At the moment, the Linux Tools profiling tools are simplifying the set of profiling tools by placing them into categories since there is overlap in functionality among the tools. There is a Memory profile category, a Timing profile category, and a Coverage profile category. Each is extensible for adding third-party profiling tools and new categories are also possible. Each category has a defaulted tool which depends on what is installed or not and this is customizable by the user. A novice user can simply perform a Timing profile and not have to pick a tool before-hand. This doesn't eliminate the short-cut issues, but it lowers the number of short-cuts presented (i.e. still isn't consistent gramatically: e.g. Profile as..->Profile Timing. For Kepler, the idea is to simplify this even further and present the user with the same CDT launch short-cuts for profiling as used for running and debugging. The previous list of profile tools would be placed in a new context menu item: e.g. Profile Actions... or something similar so that the Profile as... selections would be cleaned up. The simplification would be beneficial to the end-user in that the interface would be consistent among the three modes, settings such as program arguments and environment variables would only require setting once, and for a first-time user, an appropriate default report of their application is just a single click.
I have posted a patch to gerrit to implement this on the master branch. The patch can be found here: https://git.eclipse.org/r/9014 I have also posted the Linux Tools bits required in a separate gerrit review: https://git.eclipse.org/r/9015 should anyone like to try the change out and see how it works with the Linux Tools profiling framework. I am a commiter on the CDT project. All code is EPL, written 100% by me.
Thanks Jeff! This seems very cool. I'll try to give it a spin soon, but I may not have time until early next week.
(In reply to comment #2) > Thanks Jeff! This seems very cool. I'll try to give it a spin soon, but I > may not have time until early next week. Great. Please note that the moving of the old profiling launch short-cuts isn't done yet so you will see Local C/C++ Application in the middle of a list of items when you click Profile as...
Just a note that I started looking at this and it looks quite nice. I'd like to spend a little more time testing it before publishing some minor comments.
(In reply to comment #4) > Just a note that I started looking at this and it looks quite nice. I'd > like to spend a little more time testing it before publishing some minor > comments. Sure. Comments would be welcome. Feel free to enhance the patch if you see something obvious (you can make changes, amend the commit, and push it to gerrit to replace the current patch set). I updated the patch recently so that the Profiling Configurations dialog will show an error message for any configuration when there are no profiling tool providers installed. Before I just disabled the Profile button by marking the tab page as invalid. I also put the message in a Label on the profiling tab though I could just leave it blank since the error message shows up to let the user know what has occurred.
For others that want to try this: although the "Profile As..." context menu is present, it is useful to also have the Profile button in the main toolbar and Run menu. To get those, Window->Customize Perspective->Command Groups Availability and enable "Profile". Thanks Mikhail for pointing this out.
(In reply to comment #1) > I have also posted the Linux Tools bits required in a separate gerrit review: > > https://git.eclipse.org/r/9015 The patch for Linux Tools on Gerrit has conflicts when I try to rebase to master. Jeff can you push an updated version? You had mentioned there was more cleanup done to the Profiler launches in Linux Tools on master, which is why I'd like to rebas it. Thanks
(In reply to comment #7) > (In reply to comment #1) > > > I have also posted the Linux Tools bits required in a separate gerrit review: > > > > https://git.eclipse.org/r/9015 > > The patch for Linux Tools on Gerrit has conflicts when I try to rebase to > master. Jeff can you push an updated version? You had mentioned there was > more cleanup done to the Profiler launches in Linux Tools on master, which > is why I'd like to rebas it. > > Thanks Fixed.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #1) > > > > > I have also posted the Linux Tools bits required in a separate gerrit review: > > > > > > https://git.eclipse.org/r/9015 > > > > The patch for Linux Tools on Gerrit has conflicts when I try to rebase to > > master. Jeff can you push an updated version? You had mentioned there was > > more cleanup done to the Profiler launches in Linux Tools on master, which > > is why I'd like to rebas it. > > > > Thanks > > Fixed. Fixed again.
Thanks Jeff for this feature. I like it and I think it makes Profile be in-line with Run and Debug. I've finished the code review and put the comments in Gerrit. I'd like to test a bit more but I'll wait until you look at the review comments. Most comments are minor, with the main issue being about how do we deal with multiple extensions to the extension point. Also, I wonder if we should (or can) hide the Profile As..->Local C/C++ application option if there are no profilers installed? Exactly how it would look right now with plain CDT no Linux Tools installed. Keeping it may be a hint to the user that they could install a profiler, but is also misleading since it currently cannot be used. I'm not sure what is best. What do you think? Note that when I navigate the different profilers in the profile launch I got an NPE: !ENTRY org.eclipse.jface 4 2 2013-01-16 06:33:31.027 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.jface". !STACK 0 java.lang.NullPointerException at org.eclipse.linuxtools.internal.perf.PerfCore.loadEventList(PerfCore.java:158) at org.eclipse.linuxtools.internal.perf.PerfCore.getEventList(PerfCore.java:95) at org.eclipse.linuxtools.internal.perf.launch.PerfEventsTab.createEventTabs(PerfEventsTab.java:79) at org.eclipse.linuxtools.internal.perf.launch.PerfEventsTab.initializeFrom(PerfEventsTab.java:257) at org.eclipse.linuxtools.internal.profiling.launch.provider.CProfilingOptionsTab.initializeFrom(CProfilingOptionsTab.java:180) at org.eclipse.cdt.launch.ui.CProfilingTab.initializeFrom(CProfilingTab.java:100)
(In reply to comment #10) > Thanks Jeff for this feature. I like it and I think it makes Profile be > in-line with Run and Debug. > > I've finished the code review and put the comments in Gerrit. I'd like to > test a bit more but I'll wait until you look at the review comments. > > Most comments are minor, with the main issue being about how do we deal with > multiple extensions to the extension point. > > Also, I wonder if we should (or can) hide the Profile As..->Local C/C++ > application option if there are no profilers installed? Exactly how it > would look right now with plain CDT no Linux Tools installed. Keeping it > may be a hint to the user that they could install a profiler, but is also > misleading since it currently cannot be used. I'm not sure what is best. > What do you think? > > Note that when I navigate the different profilers in the profile launch I > got an NPE: > > !ENTRY org.eclipse.jface 4 2 2013-01-16 06:33:31.027 > !MESSAGE Problems occurred when invoking code from plug-in: > "org.eclipse.jface". > !STACK 0 > java.lang.NullPointerException > at > org.eclipse.linuxtools.internal.perf.PerfCore.loadEventList(PerfCore.java: > 158) > at > org.eclipse.linuxtools.internal.perf.PerfCore.getEventList(PerfCore.java:95) > at > org.eclipse.linuxtools.internal.perf.launch.PerfEventsTab. > createEventTabs(PerfEventsTab.java:79) > at > org.eclipse.linuxtools.internal.perf.launch.PerfEventsTab. > initializeFrom(PerfEventsTab.java:257) > at > org.eclipse.linuxtools.internal.profiling.launch.provider. > CProfilingOptionsTab.initializeFrom(CProfilingOptionsTab.java:180) > at > org.eclipse.cdt.launch.ui.CProfilingTab.initializeFrom(CProfilingTab.java: > 100) Thanks Marc. I have responded to each comment and have posted a new patch set (I found a few errors I caused in my changes). Please check my responses and the new patch set. I wonder if you could provide more information regarding the NPE you are seeing above. Can you detail what you were doing at the time of the NPE? What platform are you running on and were you able to run profiling at all? Do you have any of the profiling tools installed?
Could you provide a list or a screenshot of the plugins I should have checked out from Linux Tools to test this? My current setup with the Linux Tools patch you posted is throwing NPE's all over the place.
(In reply to comment #12) > Could you provide a list or a screenshot of the plugins I should have > checked out from Linux Tools to test this? My current setup with the Linux > Tools patch you posted is throwing NPE's all over the place. I am using CDT checked out via git into a local repository and Linux Tools checked out into a local repository. I have imported basically all the projects and then I start up a child Eclipse with all plug-ins/features from the workspace On the CDT side I have my patch rebased on top of Martin's and Camilo's (see below): commit 681d833ad4b748de294a0f5aa406e13538eb655d Author: Jeff Johnston <jjohnstn@redhat.com> Date: Fri Dec 14 19:08:29 2012 -0500 Bug 391608: RFE: Extend CDT launch to allow external profiling tool providers for "profile" short-cut mode https://bugs.eclipse.org/bugs/show_bug.cgi?id=391608 - Add a new profilingProvider extension to org.eclipse.cdt.launch to allow specification of an external profiling provider for local C/C++ launch which supplies a launch delegate and a C tab for showing in the Profiling Launch Configurations dialog - Add code to check for the extension in the CApplicationLaunchShortcut to use the extension to set profile launch attributes - Add code in LocalCDILaunchDelegate to look at the extension and use the delegate for profiling - Add a proxy tab for Profiling which uses the extension's tab for underlying methods - Enable the Local C/C++ application for profiling support Change-Id: I1bbc43656bb222320b6b095387fc4efdc227189c commit 4811216ec478de5971f300483c2c2778279a0d1c Author: Martin Oberhuber <martin.oberhuber@windriver.com> Date: Tue Jan 15 16:50:16 2013 +0100 Bug 398195 - Consider external ReadOnlyPDOMProvider in Include Browser Change-Id: Iebb2e9bd7c40e3fbfa4beb380208e06d3cb5e49e Reviewed-on: https://git.eclipse.org/r/9682 Reviewed-by: Sergey Prigogin <eclipse.sprigogin@gmail.com> IP-Clean: Sergey Prigogin <eclipse.sprigogin@gmail.com> Tested-by: Sergey Prigogin <eclipse.sprigogin@gmail.com> commit 62fa04403152027d2bf9b88c931afcdca81a946c Author: cabernal <cabernal@redhat.com> For Linux Tools, I have: commit 902663690bc6fcf08209048927f80d772bb77774 Author: Jeff Johnston <jjohnstn@redhat.com> Date: Wed Jan 16 15:44:00 2013 -0500 Bug 391608: RFE: Extend CDT launch to allow external profiling tool providers for "profile" short-cut mode https://bugs.eclipse.org/bugs/show_bug.cgi?id=391608 - Use new CDT org.eclipse.cdt.launch.profilingProvider extension to provide a launch delegate and tab for profiling local C/C++ applications Change-Id: I27f6e69ed4566aad420095db93e075ef0d9204a0 commit 6e3deb9e1873fa98986bf1567a07eea3125fff9e Author: Roland Grunberg <rgrunber@redhat.com> Date: Mon Jan 14 16:11:45 2013 -0500 Now, I am running a downloaded Eclipse 4.2 SDK with CDT and Linux Tools features installed. You should have at minimum the Linux Tools Profiling Framework feature plus Perf installed (to try this out without requiring root access as is needed for OProfile or requiring recompilation as is in the case of Gprof). You should make sure you have the perf command installed on your machine. I will attach the list of features from About Eclipse. Let me know if there are any discrepancies. Feel free to tell me your set-up so I may try and reproduce here instead.
Created attachment 225783 [details] snapshot of child eclipse and plug-ins from about eclipse
Created attachment 225784 [details] more plug-ins
Created attachment 225785 [details] more plug-ins 2
Created attachment 225786 [details] more plugi-ins 3
Created attachment 225787 [details] more plug-ins 4
(In reply to comment #14) > Created attachment 225783 [details] > snapshot of child eclipse and plug-ins from about eclipse These are just the Linux Tools plug-ins I have for the child eclipse session. Do you have details on any of the other NPE's you are experiencing?
(In reply to comment #13) > (In reply to comment #12) > > Could you provide a list or a screenshot of the plugins I should have > > checked out from Linux Tools to test this? My current setup with the Linux > > Tools patch you posted is throwing NPE's all over the place. > > I am using CDT checked out via git into a local repository and Linux Tools > checked out into a local repository. Ok, me too. > I have imported basically all the > projects and then I start up a child Eclipse with all plug-ins/features from > the workspace Me too, except I didn't import all projects. In Linux Tools, I was getting errors, so I only have in my workspace: /org.eclipse.linuxtools.binutils /org.eclipse.linuxtools.callgraph.core /org.eclipse.linuxtools.dataviewers /org.eclipse.linuxtools.dataviewers.annotatedsourceeditor /org.eclipse.linuxtools.dataviewers.charts /org.eclipse.linuxtools.dataviewers.piechart /org.eclipse.linuxtools.gcov.core /org.eclipse.linuxtools.gcov.launch /org.eclipse.linuxtools.gprof /org.eclipse.linuxtools.gprof.launch /org.eclipse.linuxtools.oprofile.core /org.eclipse.linuxtools.oprofile.launch /org.eclipse.linuxtools.oprofile.remote.launch /org.eclipse.linuxtools.oprofile.ui /org.eclipse.linuxtools.perf /org.eclipse.linuxtools.profiling.launch /org.eclipse.linuxtools.profiling.launch.remote /org.eclipse.linuxtools.profiling.ui /org.eclipse.linuxtools.profiling.ui.capability /org.eclipse.linuxtools.systemtap.ui.consolelog /org.eclipse.linuxtools.systemtap.ui.dashboard /org.eclipse.linuxtools.systemtap.ui.dashboardextension /org.eclipse.linuxtools.systemtap.ui.editor /org.eclipse.linuxtools.systemtap.ui.graphicalrun /org.eclipse.linuxtools.systemtap.ui.graphing /org.eclipse.linuxtools.systemtap.ui.graphingapi.nonui /org.eclipse.linuxtools.systemtap.ui.graphingapi.ui /org.eclipse.linuxtools.systemtap.ui.ide /org.eclipse.linuxtools.systemtap.ui.logging /org.eclipse.linuxtools.systemtap.ui.structures /org.eclipse.linuxtools.systemtap.ui.systemtapgui /org.eclipse.linuxtools.tools.launch.core /org.eclipse.linuxtools.tools.launch.ui /org.eclipse.linuxtools.valgrind.cachegrind /org.eclipse.linuxtools.valgrind.core /org.eclipse.linuxtools.valgrind.helgrind /org.eclipse.linuxtools.valgrind.launch /org.eclipse.linuxtools.valgrind.launch.remote /org.eclipse.linuxtools.valgrind.massif /org.eclipse.linuxtools.valgrind.memcheck /org.eclipse.linuxtools.valgrind.ui /org.eclipse.linuxtools.valgrind.ui.editor The commit history I have matches the one you have for both CDT and Linux Tools. > Now, I am running a downloaded Eclipse 4.2 SDK with CDT and Linux Tools > features installed. I have 4.2M3 with RSE, EGit/JGit and SWTChart. No CDT or Linux Tools in the development Eclipse. > You should have at minimum the Linux Tools Profiling Framework feature plus > Perf installed (to try this out without requiring root access as is needed > for OProfile or requiring recompilation as is in the case of Gprof). You > should make sure you have the perf command installed on your machine. I don't have Perf on my linux box. I can install it, but I don't think a missing Perf should be allowed to cause NPEs. However, this is in the Linux Tools part so it is your call. I'll run some tests without Linux Tools, which is really the part I must pay attention too. But I would like to see this feature at work with Linux Tools eventually :)
Testing with CDT only looks good. Just a couple more comments in Gerrit to look at. One general issue: when a Profile As -> Local C/C++ application without Linux Tools, I get the new error message, however, in the Debug view, there is an entry that appears and I can't get rid of it. I'll try to figure out about what's goind on with the NPE's when I run with Linux Tools
Something just hit me. The platform provides a way to add new delegate for debug and run through extension points. My guess is that it would work for Profiling as well. Basically Linux Tools would define a new profiling launch delegate and its tabs, and the platform would make it available under the CDT-defined launch configuration type. I haven't looked into it just yet but that may mean we only need to add the concept of Profile As->Local C/C++ App in CDT and let the platform delegate it to Linux Tools. The tabs and launch delegate from Linux Tools would be called directly. For instance, o.e.cdt.dsf.gdb provides the debug launch delegates in its plugin.xml file. Is this something you looked into?
Created attachment 225800 [details] Prototype of simpler fix I tried a prototype of the idea I mentioned. It seems to work, if I understood what you were aiming for. Can you look at the attached patch and let me know what you think? It does not seem to require any changes in CDT, all changes are in Linux Tools. We could decide to put the new launch shortcut in CDT if we wanted to allow other plugins to make use of it though. What I wasn't able to test is to actually do a profiling launch since I didn't know the details from Linux Tools, but I think it should work fine. Sorry I didn't think of this sooner.
(In reply to comment #23) > Created attachment 225800 [details] > Prototype of simpler fix > > I tried a prototype of the idea I mentioned. It seems to work, if I > understood what you were aiming for. Can you look at the attached patch and > let me know what you think? > > It does not seem to require any changes in CDT, all changes are in Linux > Tools. We could decide to put the new launch shortcut in CDT if we wanted > to allow other plugins to make use of it though. > > What I wasn't able to test is to actually do a profiling launch since I > didn't know the details from Linux Tools, but I think it should work fine. > > Sorry I didn't think of this sooner. Yes, much simpler. Let me play around with it to get it working and I'll report back here.
(In reply to comment #24) > (In reply to comment #23) > > Created attachment 225800 [details] > > Prototype of simpler fix > > > > I tried a prototype of the idea I mentioned. It seems to work, if I > > understood what you were aiming for. Can you look at the attached patch and > > let me know what you think? > > > > It does not seem to require any changes in CDT, all changes are in Linux > > Tools. We could decide to put the new launch shortcut in CDT if we wanted > > to allow other plugins to make use of it though. > > > > What I wasn't able to test is to actually do a profiling launch since I > > didn't know the details from Linux Tools, but I think it should work fine. > > > > Sorry I didn't think of this sooner. > > Yes, much simpler. Let me play around with it to get it working and I'll > report back here. I have revised the Linux Tools patch and have posted for review. The only issue would be the internal reference to CDT's org.eclipse.cdt.debug.internal.ui.launch.CApplicationLaunchShortcut class which could be handled in the CDT either by making org.eclipse.linuxtools.profiling.launch an x-friend for the package or by making the class public. I am switching this bug over to Linux Tools since it is being done on this side.
(In reply to comment #25) > I have revised the Linux Tools patch and have posted for review. Note that in the prototype I attached, I kept all the old CDT id's and used hard-code strings in the plugin.xml file. I also kept the original copyright header. You may want to clean that up. > The only issue would be the internal reference to CDT's > org.eclipse.cdt.debug.internal.ui.launch.CApplicationLaunchShortcut class I'm not sure if using the CDT CApplicationLaunchShortcut is correct. You may need to setup other attributes for the profiler, and that class won't do that for you. You could override it and make the changes you need, or re-write it only keeping the parts that are relevant.
(In reply to comment #26) > (In reply to comment #25) > > > I have revised the Linux Tools patch and have posted for review. > > Note that in the prototype I attached, I kept all the old CDT id's and used > hard-code strings in the plugin.xml file. I also kept the original > copyright header. You may want to clean that up. > > > The only issue would be the internal reference to CDT's > > org.eclipse.cdt.debug.internal.ui.launch.CApplicationLaunchShortcut class > > I'm not sure if using the CDT CApplicationLaunchShortcut is correct. You > may need to setup other attributes for the profiler, and that class won't do > that for you. You could override it and make the changes you need, or > re-write it only keeping the parts that are relevant. The idea is that the configuration is shared between CDT Run/Debug and Linux Tools Profile. The set up done in the CDT CApplicationShortcut is required for using that configuration for future Run/Debug usage so either we copy it or let the CDT control the creation. I opted for the 2nd method which means less future maintenance issues. I could cleanse the reference by proxying the ILaunchShortcut2 APIs and dynamically creating the CDT's shortcut via its extension id so there is no internal import required. I have designed the Linux Tools code to look for the case where a configuration has been created for Run/Debug and now is being used for Profile (this will be any existing configuration prior to installing the new version of Linux Tools). The configuration delegate handles this case and ensures the profiling defaults are added (like I did in the previous design within the shortcut). Once the profiling options are set up, if the user has uninstalled the Profiling tool specified for the configuration, there is a warning dialog presented and no profiling occurs. The tab similarly checks for this and will set up defaults for the first time the configuration is presented. Regarding the ids, I had wondered about those. I will change them to be under the Linux Tools namespace.
(In reply to comment #27) > I have designed the Linux Tools code to look for the case where a > configuration has been created for Run/Debug and now is being used for > Profile (this will be any existing configuration prior to installing the new > version of Linux Tools). Nice! With that, I think we can improve the solution. I am concerned that another plugin may also add a profiling launch shortcut called "Local C/C++ Application". I know it is far fetched, but that launch shortcut really should be in CDT itself. Since you can re-use CDT's CApplicationShortcut, we could leave that out of Linux Tools, and simply add the new launch delegate for profiling. That way, if someone else wants to have a "Profile As->Local C/C++ Application", they can use the CDT one instead of defining their own, and clashing with the one from Linux Tools? What do you think?
(In reply to comment #28) > (In reply to comment #27) > > > I have designed the Linux Tools code to look for the case where a > > configuration has been created for Run/Debug and now is being used for > > Profile (this will be any existing configuration prior to installing the new > > version of Linux Tools). > > Nice! With that, I think we can improve the solution. I am concerned that > another plugin may also add a profiling launch shortcut called "Local C/C++ > Application". I know it is far fetched, but that launch shortcut really > should be in CDT itself. Since you can re-use CDT's CApplicationShortcut, > we could leave that out of Linux Tools, and simply add the new launch > delegate for profiling. > > That way, if someone else wants to have a "Profile As->Local C/C++ > Application", they can use the CDT one instead of defining their own, and > clashing with the one from Linux Tools? > > What do you think? Actually, I think that may be a step back. At the moment, the CDT does not mark the CApplicationShortcut as supporting Profile. In the current scenario, if Linux Tools is not installed, the user will not see the Profile as->Local C/C++ Application menu item which I believe to be the correct behaviour. There are checks in the Linux Tools code if plug-ins are uninstalled and there are nice error messages to the end-user. In your revised scenario, they will see Profile as Local C/C++ application when Linux Tools isn't installed, but it will not perform any profiling and won't give a nice error message without some modification of the CDT short-cut (perhaps recognize that there are no profiling launch delegates for the type??). In addition, I do not know if the system even prevents another project from adding their own short cut with the same label (i.e. shows two "Local C/C++ Application" shortcuts) in which case, this doesn't accomplish much. I would rather have the current scenario and if some other project (let's say RDT) wants the short-cut as well, then there will need to be some cooperation. Even in the new scenario you propose, this type of cooperation is still required as there isn't a common framework for which to add tools. I have posted a new patch that removes the internal reference (using the extension id and a proxy), fixes up the ids, and also has nicer error messages when we know the profiling tool name. I agree that ultimately, I would like to see the profiling stuff inside the CDT which is why I started the way I did but this is much less intrusive.
(In reply to comment #29) > Actually, I think that may be a step back. At the moment, the CDT does not > mark the CApplicationShortcut as supporting Profile. In the current > scenario, if Linux Tools is not installed, the user will not see the Profile > as->Local C/C++ Application menu item which I believe to be the correct > behaviour. Yes, that is how it should behave. The good thing is that if there is no launch delegate supporting 'profile' then the shortcut will not be shown; in fact "Profile As" won't be shown at all, which seems even better. So, I thought that by creating the launch delegate in Linux Tools, things would work great. The problem is that the CDT provides a Launch Group delegate which does support 'profile'. If we remove the 'profile' from that delegate, the Profile as->Local C/C++ Application menu is not shown if Linux Tools is not installed. > I do not know if the system even prevents another project from adding their > own short cut with the same label (i.e. shows two "Local C/C++ Application" > shortcuts) in which case, this doesn't accomplish much. No, I don't expect the system will prevent it. However, if the shortcut is in CDT the other project has the option of not defining that shortcut itself. If the shortcut is in Linux Tools, then the other project will be forced to define the shortcut itself, so it can be visible when Linux Tools is not installed; but if Linux Tools is installed, then I assume there will be two of those launch shortcuts visible. If it wasn't for the Launch Group delegate of the CDT, I believe the solution I was thinking of would only require to add 'profile' to the existing CDT launch shortcut. But while Launch Group supports 'profile' I agree this is not good enough. I think removing 'profile' from the Launch Group delegate makes sense. In fact, running CDT on its own and having the Launch Group for Profile seems wrong, since no real configuration can be put in a launch group anyway. Since Linux Tools provides the Profile launch config, Launch Group for Profile should also be created by Linux Tools, I think. This can be done easily by creating a delegate named Launch Group and having it use the CDT's MultiLaunchConfigurationDelegate.java class. The annoying thing is that it is an internal class. But then we could use your proxy trick and be in business. So, if you are willing to try it, you can 1- add 'profile' to the existing CDT launch shortcut 2- remove 'profile' from the existing CDT Launch Group delegate 3- remove the launch shortcut from your Linux Tools patch 4- add a launch delegate to your Linux Tools patch I can post a couple of patches if that makes my long winded explanation more clear.
I'm now worried about removing 'profile' from the Launch Group. It would break the launch group for vendors who already use it with 'profile', and it won't be obvious they need to create their own launch delegate. I give up :) Let's keep the whole think in Linux Tools.
Jeff, could you abandon the CDT gerrit review (9014) since it won't be needed anymore?
(In reply to comment #31) > I'm now worried about removing 'profile' from the Launch Group. It would > break the launch group for vendors who already use it with 'profile', and it > won't be obvious they need to create their own launch delegate. > > I give up :) Let's keep the whole think in Linux Tools. Good, we agree :) The current design is clean, elegant, and works as expected without any modification to the CDT. If the CDT wants to take over profiling for the Local C/C++ Application, then we can always revisit an extension to allow Linux Tools and others to contribute to that; akin to my earlier designs. Thanks for all your time reviewing this and for your much simpler design suggestion. I have abandoned the CDT part of the change in gerrit.
Comment on attachment 225800 [details] Prototype of simpler fix Marc's patch has been replaced by the gerrit patch: https://git.eclipse.org/r/9015 which was committed with hash: 575da32a78b8111e85688c73fe70eaf84737f17b
Patch has been applied.
*** Bug 389443 has been marked as a duplicate of this bug. ***
