Community
Participate
Working Groups
Build Identifier: 20110519-1049 1) Create a Cygwin project or if you have exiting project then in the project context menu select "Build Configurations > Clean All" 2) In the context menu select "Build Configurations > Build All" 3) Click on the hammer button to build any configuration or run "Build All" again. Instead of running just "make all" that wouldn't do anything, the CDT performs a full rebuild, i.e. runs "make clean" first, then "make all". If you run "Build All" for the third time, then it builds OK. In CDT 7, it appears that after project creation or clean command, the CDT builder is set to FULL_BUILD. After a FULL_BUILD, CommonBuilder for some reason sets all build configurations the state that cfg.needsRebuild() returns TRUE. Therefore each configuration is rebuilt again. I haven't yet looked at CDT 8 code, but this bug is also in Indigo CDT RC1 package. Reproducible: Always
I ran into the same problem in CDT 8.1 with the headless build, where it is more pronounced because every build is a FULL_BUILD. Doing a headless build of more than one configuration of a managed project at once (or in fact any way of FULL_BUILDing multiple configurations at once, as Alex observed) will mark all configurations as needing a full rebuild, i.e. the next build will do a "make clean" first. Expected behavior, as far as I understand the code, is that only the configurations that were not built should be marked as needing a rebuild (which I'm not happy with either, but I understand is necessary until CDT configurations are unified with platform configurations). The cause is a bug in org.eclipse.cdt.core.settings.model.util.ListComparator#getAdded, called from the org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.OtherConfigVerifier constructor: it appears to be supposed to compute the set difference of two collections, i.e. keep only those elements from the first argument in the result that are not equal to any element of the second argument. What it does instead is keep those that are not equal to *all* elements of the second argument, which unless the second argument only contains a single (distinct) element amounts to keeping everything. Steps to reproduce: 1. Make a new C project using the "Hello World" template and all its default settings. I've tried this on Linux because I just happened to have a compatible compiler (GCC) installed there, but behavior should be the same everywhere. The bug was originally found using a custom toolchain on Windows. 2. Build either of its two configurations headlessly several times and observe that the second and all further builds will not do a "make clean" (this is the expected behavior): eclipse -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data /home/cwalther/workspace-headlessbuild -consoleLog -nosplash -import file:///home/cwalther/workspace-cpptest/helloworld -build helloworld/Debug 3. Build both configurations at once several times: ... -build "helloworld/Debug|Release" Expected behavior: The second and all further builds should not be rebuilds, i.e. not do a "make clean", just a "make all" (which has nothing to do since the output is already up to date). Actual behavior: All builds include a "Clean-only build" ("make clean") in both configurations and therefore needlessly rebuild everything. I have a fix for this, as well as a unit test that catches the ListComparator failure. However, I'm wondering if ListComparator should be removed entirely - it is only used in three places in CDT, one of them commented out, and seems somewhat redundant with Java Collections Framework functionality. It's exported from the plugin though, so others might be using it. I'm a bit confused as to whether contributions are still expected as patches attached here, or through Gerrit. http://wiki.eclipse.org/CDT/git#Posting_patches_on_Bugzilla says "Until Eclipse provides a Gerrit instance for all projects to use, the mechanism for community contributions remains patches attached to Bugzilla items", however according to information on the same page, and occasional mentions on the mailing list, Gerrit appears to be in operation already. I'm going to attach patches for now, but will be glad to try Gerrit if I'm told to.
Created attachment 220772 [details] unit test
Created attachment 220773 [details] proposed fix
