Community
Participate
Working Groups
Build Identifier: In #69922 a key binding for rebuilding the last make target was introduced. There is a preference option to either look for the last make target in the currently selected folder or in the project's root folder. When working with various build configurations (e.g. Debug and Release) it would be helpful to use the build location of the active build configuration to look for the last make target. Consider the following project structure: myproj ->src src1.cpp ->Debug Makefile ->Release Makefile Reproducible: Always
Created attachment 185727 [details] Preference option to look for the last make target in the build location of the active build config
AFAICS the option to build from project root uses build directory as CWD. Isn't it sufficient to define your targets in project root of the Make Targets View in your workflow?
(In reply to comment #2) > AFAICS the option to build from project root uses build directory as CWD. Isn't > it sufficient to define your targets in project root of the Make Targets View > in your workflow? Of course, this would be possible. And it is a workaround I am currently using. But this solution has some drawbacks. I have around 10-20 different make targets (applications) per build configuration. There are 4 build configurations (Debug/Release for Linux/Windows). Putting all of these targets in project root would render the Make Target View confusing. It is very handy to have the build configurations in different folders in the Make Target View. In this case it is also not necessary to rename the targets according to the build configuration (e.g. App1_Debug_Linux, App1_Release_Linux etc.).
Andrew, do you think this is a valid enhancement request?
Well, I am unsure. The F9 key never stuck with me, I am mouse user apparently. In fact, I was somewhat confused with the Make Target preferences looking after a year has passed. It took me checking F1 help to recall what the 2 options mean, thankfully the help is up to date. With a fresh look, I wonder why F9 wouldn't just run the last target - wherever it happened to be. What about option like that, would it fit your flow?
(In reply to comment #5) > With a fresh look, I wonder why F9 wouldn't just run the last target - wherever > it happened to be. What about option like that, would it fit your flow? That option would be OK for my workflow. AFAIK, we did not implement it because the last make target is currently stored per folder. To support this new option we need to store a "global" last make target for the whole project (or whole workspace?). But I would suggest that we will keep the two existing options (use last make target in project root/selected folder). I think there are also use cases that cover these options.
(In reply to comment #6) > (In reply to comment #5) > > With a fresh look, I wonder why F9 wouldn't just run the last target - > wherever > > it happened to be. What about option like that, would it fit your flow? > That option would be OK for my workflow. AFAIK, we did not implement it because > the last make target is currently stored per folder. To support this new option > we need to store a "global" last make target for the whole project (or whole > workspace?). I think it would be sufficient to use on the project level "lastTarget" session property and add "lastTargetContainer". It should be OK since the options are exclusive. I think the target like that should be in the scope of a project. > But I would suggest that we will keep the two existing options (use last make > target in project root/selected folder). I think there are also use cases that > cover these options. Yes, I agree. But I think the new option should be the default one because it is easier to understand. It's just plain "run the last target".
This should interface well with managed build too. On bug 333992 I'm adding the concept of build history -- it would be good if make targets could plug into that.
Note as FYI that make targets don't work with Internal Builder - bug 304774.
(In reply to comment #8) > This should interface well with managed build too. On bug 333992 I'm adding the > concept of build history -- it would be good if make targets could plug into > that. I think it would be nice if eventually "Run Make Target" and "Run Command From Console" idea converged to Launch and be able to define and use "Run Configurations" facilities.
Created attachment 188413 [details] Preference option to rebuild actual last target The new property "lastTargetContainer" is stored per project. I introduced a new default preference to build the actual last target of the selected project irrespective of the selected container. The two already existing options are still there. I only renamed some internal variables to make them better understandable.
You should obsolete the previous patch in bugzilla. I am getting following exception when trying to rerun last target if that target located under project root (using new default preference): java.lang.IllegalArgumentException: Path must include project and resource name: /Hello1 at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63) at org.eclipse.core.internal.resources.Workspace.newResource(Workspace.java:2133) at org.eclipse.core.internal.resources.Container.getFolder(Container.java:221) at org.eclipse.cdt.make.ui.actions.BuildLastTargetAction.run(BuildLastTargetAction.java:49) at org.eclipse.ui.actions.ActionDelegate.runWithEvent(ActionDelegate.java:70) at org.eclipse.ui.internal.handlers.ActionDelegateHandlerProxy.execute(ActionDelegateHandlerProxy.java:281) at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476) at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508) at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:468) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:786) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:885) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:567) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$3(WorkbenchKeyboard.java:508) at org.eclipse.ui.internal.keys.WorkbenchKeyboard$KeyDownFilter.handleEvent(WorkbenchKeyboard.java:123) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1262) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1052) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1062) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1104) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1100) at org.eclipse.swt.widgets.Widget.wmKeyDown(Widget.java:1809) at org.eclipse.swt.widgets.Control.WM_KEYDOWN(Control.java:4860) at org.eclipse.swt.widgets.Tree.WM_KEYDOWN(Tree.java:6018) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4539) at org.eclipse.swt.widgets.Tree.windowProc(Tree.java:5886) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4933) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2523) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3713) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2697) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2661) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2495) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
I also briefly looked at the code and have some comments: > private static final String PREF_BUILD_LAST_PROJECT = "MakeTargetPrefs.buildLastTarget.projectl"; //$NON-NLS-1$ You should change the preference if you change the semantics, that is correct. But I would rather prefer more explicit spelling instead 'l' character in "projectl". Could you remind me why name of target is being converted to path in following code? BuildLastTargetAction: > IPath path = new Path(target.getName()); > container.setSessionProperty(new QualifiedName(MakeUIPlugin.getUniqueIdentifier(), "lastTarget"), //$NON-NLS-1$ > path.toString());
Created attachment 188554 [details] Preference option to rebuild actual last target I fixed the exception and did some code clean up (projectl was a typo :) ). I also fixed another bug when you switch from the preference option "project root" to "selected project". The property lastTargetContainer was not set correctly then. I noticed that the key bindings (F9 and Shift-F9) do not work until the first time you select something in the Project Explorer. But I don't know how to fix (or debug) this. Any idea?
Created attachment 188558 [details] Preference option to rebuild actual last target Gotcha. The key bindings now work from the beginning! I had to remove the definitionId from plugin.xml. I got this idea from bug #300526 (to be honest I don't understand it but the bug description said something about removing definitionId and key bindings at least it works). In addition, I had to add a handler for the BuildTargetAction to get its key binding working correctly with the same "trick".
(In reply to comment #13) > Could you remind me why name of target is being converted to path in following > code? It seems that there is still something wrong with that. If I create a target having slash in its name (ex. "222/abc") it does not participate in "Last" target. Instead I am getting the popup. (In reply to comment #14) > projectl was a typo :) There is a change in what the property value "MakeTargetPrefs.buildLastTarget.project" means. Before the change it meant "last target from a project root folder". After the change the same value means "last target from the whole project". So those who set that value in preferences will be affected. However I do not see that as a real problem, you can spin it for a user as changing the defaults. And it is clearer in the code that way (the new way). Some comments about the code: - Tags "lastTarget" and "lastTargetContainer" are used in several places, you should use a constant for that. Not sure how it slipped last time :) - Warning about unused import in BuildTargetAction.java > Gotcha. The key bindings now work from the beginning! Nice! I filed separate bug 336536 about that couple days ago but it's OK. We can use this bug.
One more, for @since (BuildTargetHandler) you need to use a plugin version from MANIFEST.MF. For org.eclipse.cdt.make.ui that is 7.1 currently. API tooling would tell you the number if you set it up.
Created attachment 188726 [details] Preference option to rebuild actual last target of current project >It seems that there is still something wrong with that. If I create a target >having slash in its name (ex. "222/abc") it does not participate in "Last" >target. Fixed. >Tags "lastTarget" and "lastTargetContainer" are used in several places, you >should use a constant for that. Fixed. >for @since (BuildTargetHandler) you need to use a plugin version from >MANIFEST.MF. For org.eclipse.cdt.make.ui that is 7.1 currently. Fixed.
(In reply to comment #18) > Created attachment 188726 [details] > Preference option to rebuild actual last target of current project I am getting NPE in following scenario now: - the preference is set to build from project - run make target (named with slash "aaa/bbb/ccc") from project root - in PE context menu choose Make Targets->Build (or Shift-F9). Nothing happens - on second attempt getting an exception: java.lang.NullPointerException at org.eclipse.cdt.make.internal.core.MakeTargetManager.findTarget(MakeTargetManager.java:154) at org.eclipse.cdt.make.ui.actions.BuildTargetAction.run(BuildTargetAction.java:80) at org.eclipse.cdt.make.ui.actions.BuildTargetHandler.execute(BuildTargetHandler.java:38) at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:293) at org.eclipse.core.commands.Command.executeWithChecks(Command.java:476) at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508) at org.eclipse.ui.internal.handlers.HandlerService.executeCommand(HandlerService.java:169) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:468) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:786) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:885) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:567) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$3(WorkbenchKeyboard.java:508) at org.eclipse.ui.internal.keys.WorkbenchKeyboard$KeyDownFilter.handleEvent(WorkbenchKeyboard.java:123) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1525) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1257) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1267) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1294) at org.eclipse.swt.widgets.Widget.gtk_key_press_event(Widget.java:730) at org.eclipse.swt.widgets.Control.gtk_key_press_event(Control.java:2977) at org.eclipse.swt.widgets.Composite.gtk_key_press_event(Composite.java:734) at org.eclipse.swt.widgets.Tree.gtk_key_press_event(Tree.java:1977) at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1743) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4964) at org.eclipse.swt.widgets.Tree.windowProc(Tree.java:3505) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4369) at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method) at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:8256) at org.eclipse.swt.widgets.Display.eventProc(Display.java:1239) at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2258) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3168) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2697) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2661) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2495) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
Created attachment 188839 [details] Preference option to rebuild actual last target of current project >I am getting NPE in following scenario now: >- the preference is set to build from project >- run make target (named with slash "aaa/bbb/ccc") from project root >- in PE context menu choose Make Targets->Build (or Shift-F9). Nothing happens >- on second attempt getting an exception: Oh, this was an old bug :) It seems that nobody expected make targets with a slash in their name and carelessly put them into an IPath class. I fixed this one. Should be the last one of this kind.
*** cdt cvs genie on behalf of agvozdev *** bug 333113: Rebuild last target: option to use build location of active build configuration Patch from Axel Mueller [*] MakeTargetDialog.java 1.33 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.ui/src/org/eclipse/cdt/make/ui/dialogs/MakeTargetDialog.java?root=Tools_Project&r1=1.32&r2=1.33 [*] BuildTargetAction.java 1.15 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.ui/src/org/eclipse/cdt/make/ui/views/BuildTargetAction.java?root=Tools_Project&r1=1.14&r2=1.15 [*] DeleteTargetAction.java 1.17 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.ui/src/org/eclipse/cdt/make/ui/views/DeleteTargetAction.java?root=Tools_Project&r1=1.16&r2=1.17 [*] BuildTargetAction.java 1.13 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.ui/src/org/eclipse/cdt/make/ui/actions/BuildTargetAction.java?root=Tools_Project&r1=1.12&r2=1.13 [+] BuildTargetHandler.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.ui/src/org/eclipse/cdt/make/ui/actions/BuildTargetHandler.java?root=Tools_Project&revision=1.1&view=markup [*] BuildLastTargetAction.java 1.4 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.ui/src/org/eclipse/cdt/make/ui/actions/BuildLastTargetAction.java?root=Tools_Project&r1=1.3&r2=1.4 [*] MakeResources.properties 1.60 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.ui/src/org/eclipse/cdt/make/internal/ui/MakeResources.properties?root=Tools_Project&r1=1.59&r2=1.60 [*] TargetBuild.java 1.19 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.ui/src/org/eclipse/cdt/make/ui/TargetBuild.java?root=Tools_Project&r1=1.18&r2=1.19 [*] plugin.xml 1.88 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.ui/plugin.xml?root=Tools_Project&r1=1.87&r2=1.88 [*] MakePreferencePage.java 1.15 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.ui/src/org/eclipse/cdt/make/internal/ui/preferences/MakePreferencePage.java?root=Tools_Project&r1=1.14&r2=1.15
(In reply to comment #20) > Created attachment 188839 [details] > Preference option to rebuild actual last target of current project I committed the patch to the HEAD, thanks for the contribution. But there is one inaccuracy left. In "From selected project" mode - if there was no target run yet F9 shows the list of targets to select from. But the list shows only targets from the project root. Could you fix that too? Shift-F9 shows the list from all folders. One more thing, there is user help, if you could update it that would be great. The help is also under CVS, see /org.eclipse.cdt.doc.user/reference/cdt_u_make_pref.htm.
*** cdt cvs genie on behalf of agvozdev *** bug 333113: Removed Java 6 usage [*] BuildLastTargetAction.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.ui/src/org/eclipse/cdt/make/ui/actions/BuildLastTargetAction.java?root=Tools_Project&r1=1.4&r2=1.5 [*] BuildTargetAction.java 1.14 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.ui/src/org/eclipse/cdt/make/ui/actions/BuildTargetAction.java?root=Tools_Project&r1=1.13&r2=1.14
Created attachment 189051 [details] Show possible targets recursively if last target is empty and "from selected project" mode is selected >But there is one inaccuracy left. In "From selected project" mode - if there was >no target run yet F9 shows the list of targets to select from. But the list >shows only targets from the project root. Could you fix that too? Shift-F9 shows >the list from all folders. This patch should fix this.
Created attachment 189052 [details] update for user help >I committed the patch to the HEAD, thanks for the contribution. Thanks for commiting and helping to improve my initial patch. >One more thing, there is user help, if you could update it that would be great. Update for user help.
Committed patches to the HEAD (8.0). Thanks for the patches, again!
*** cdt cvs genie on behalf of agvozdev *** bug 333113: Rebuild last target: option to use build location of active build configuration Patch from Axel Mueller [*] BuildLastTargetAction.java 1.6 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.make.ui/src/org/eclipse/cdt/make/ui/actions/BuildLastTargetAction.java?root=Tools_Project&r1=1.5&r2=1.6 [*] cdt_u_make_pref.htm 1.9 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-doc/org.eclipse.cdt.doc.user/reference/cdt_u_make_pref.htm?root=Tools_Project&r1=1.8&r2=1.9
