Community
Participate
Working Groups
How to reproduce: 1) Create a managed C/C++ project 2) Move to project Properties > C/C++ Build 3) If Behavior tab enable parallel build. Let's say defined job count is 2. 4) If Builder Settings tab disable "Use default build command" and see promoted command. Should be 'make -j2' 5) If Builder Settings tab let's update by hand build command to 'make -j3' 6) Move to Behavior tab then Builder Settings tab back. 7) See build command is now 'make -j3 -j2'
New Gerrit change created: https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/171735
New Gerrit change created: https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/171951
Gerrit change https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/171951 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=1d226f92731b30e3894ccdf884341e58d9990508
Needs a N&N entry due to change in behaviour - see Marc-Andre's comment in the gerrit: I'm not 100% sure about this change. I've used this build command field in the case to replace 'make' with a drop-in replacement, like 'gmake'. Perhaps one could also use field to specify an absolute path to 'make'. Then in those case you'd want to preserve the other flags as configured in the UI. As it is, this change would likely break existing configs and probably warrants an entry in N&N as projects would need to be updated to account for this.
> I'm not 100% sure about this change. I've used this build command field in > the case to replace 'make' with a drop-in replacement, like 'gmake'. Perhaps > one could also use field to specify an absolute path to 'make'. Then in > those case you'd want to preserve the other flags as configured in the UI. It may be better to have multiple text fields to match the contents of .cproject where the command and flags are separate. That would mean that where the command was non-default (e.g. gmake) but the args were default (e.g. null) you would get it still.
(In reply to Jonah Graham from comment #5) > It may be better to have multiple text fields to match the contents of > .cproject where the command and flags are separate. That would mean that > where the command was non-default (e.g. gmake) but the args were default > (e.g. null) you would get it still. Is this the way we want to go?
I personally don't think this is a bug/issue. First of all running "make -j2 -j3" works fine (I assume that -in compliance with gcc habits- the latest option will be used but I didn't check) So the only possible impact is that you may use a different number of threads than expected. I would assume someone smart enough to uncheck "use default build command" and modify the build command; would be smart enough to see that look at the console and see the "make -j2 -j3" line and figure things out. My conclusion "After uncheking the option and modifying the build command as suggested; everything works fine, possible side effect: different number of build threads than expected are being used" So not an issue. Now look at the option "generate makefiles automatically" If you uncheck this option many of the changes done in the settings will not be taken into account. New files added to the project will not be taken into account. Deleting the configuration output folder (like Release) will make building the project impossible. My conclusion "After uncheking the option; secondary steps will lead to a blocking situation requiring to turn the option back on. My proposal: leave as is.
Reading up more on this issue I see that the proposed solution is <disable the settings when one disables "use default build command"> I don't think this is a good solution. My main comment is that there are very valid reasons to change the default make command without wanting to disable setting the options. A) Stuff like using a FQN for make because... there are many makes in the world and having a sh in the make folder changes some makes to behave differently. B)you may not want make in the path and there fore you can not use the ""default make command" as default cdt default build command is make without FQN. C) make may come with a desired option without a GUI. (very unlikely but this is why you have this kind of stuff) D) All kind of creative solutions. Like I remember replacing the default build command by a script that would launch make and dump the actual commands I got. Secondly only "disabling the GUI" is not going to cut it. Assume I set parallelbuild to on with 2 threads and then opt not to use the default build command and set it to make -j3 You will still get "make -j3 -j2" as build command. But now you can no longer undo the -j2 without turning "default build command" on To get "make -j3" as build command you must modify the code that generates the command. But doing so makes it impossible to quickly set the path (keeping the same settings) My conclusion: The current solution is not perfect but I can't think of something that is really better. Only turning of the GUI may look better to you but it looks worse to me.
New Gerrit change created: https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/173118
New Gerrit change created: https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/173126
New Gerrit change created: https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/173119
I would like to revert this change for 10.1.0 and then restore it with the follow up in 10.2.0 M1. Please let me know if there is any objection to reverting this for 10.1.
Change reverted for 10.1 to be revisited in 10.2
Gerrit change https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/173126 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=1d0bc6992f27e17d1c7bcb933e482672377c9808
Gerrit change https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/173118 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=b6b66b54579326a95ce1a11bf98ec78392c99b05
All done now - N&N updated https://wiki.eclipse.org/CDT/User/NewIn103#Build
