Community
Participate
Working Groups
Build ID: Build id: I20080617-2000 Steps To Reproduce: 1. create a new configuration for a given project : Properties -> C/C++ build -> manage configuration -> new -> ... -> apply -> ok 2. quit eclipse 3. restart eclipse: the configuration has not been saved. More information: When restarting eclipse, the configuration that was created during the previous session does not appear in the "build" icon (the hammer). If now you look at: Properties -> C/C++ build -> manage configuration, it does not appear in the list but the formerly existing configuration that was used to "copy settings from" appears twice.
Mac specific or you have some other specific settings? Worksforme just fine on WinXp with virgin installation 3.4+5.0.0. Maybe you can try in fresh empty workspace?
(In reply to comment #1) Same with a fresh empty workspace. Same with Linux 32 bits.
Happens on Linux 64 bit too. Version: 3.4.0 Build id: I20080617-2000 CDT: 5.0.0.200806171202
I can reproduce this with the Windows version too. Here is what I did: - created a new C++ makefile project with 'Other toolchain' - now I have a single configuration called Default - added a new build configuration under 'C/C++ Build' called Debug - changed the build directory in the Debug configuration to ${workspace_loc:/TestProject/Debug} - quit eclipse, restart - now I have two configurations, both named Default Version: 3.4.0 Build id: I20080617-2000 CDT: 5.0.0.200806171202
I, too, am experiencing this problem under WinXP. Originally I noticed the behavior documented above by Akos Ladanyi. Now I have tried creating a new workspace and reinstalling eclipse from scratch and am finding the problems in the original bug report. Interestingly, if you search in your project's .cproject file for the missing build configuration, it is, in fact, there. Version: 3.4.0 Build id: I20080617-2000
I can confirm this bug. Steps to reproduce: I'm using a "fresh" installation of eclipse (Version: 3.4.0, Build id: I20080617-2000) and CDT (Version: 5.0.0.200806171202, Build id: 200806171202) on WinXP. After creating a new C Makefile Project with 'Other Toolchain' a have a 'Default' build configuration. 1) open project properties 2) C/C++ Build 3) Manage Configurations... 4) New... 5) enter name and press OK 6) press OK again (to quit 'Manage Configurations...') 7) press 'Apply' 8) press OK (to quit project properties) 9) close project (or exit eclipse) 10) open project (or start eclipse) => Voilá the new configuration is lost and at 'Manage Configurations...' dialog you can see two 'Default' configurations. Btw. in the .cproject file there are three build configurations (two 'Default' and the new one) If you do the same procedure without pressing 'Apply' all works fine. Furthermore you can add several build configurations one after another by this procedure without quitting the project properties dialog but you must not press the 'Apply' button. It seems that the 'Apply' button causes the confusion.
You spelled this out down to exact keys but I still can't reproduce. Fresh installation of eclipse with matching numbers, fresh workspace. No other plugins installed. WinXP. I am getting 2 configurations after reopening of the project, one is "Default" and another is "New". No duplicates. 2 correct ones in .cproject. This is very puzzling.
Created attachment 113080 [details] broken C project
Ok, my first description is not bullet proof to reproduce the bug. I hope that my second description will do it. Very important are the steps 12, 13 and 14! You must select the new configuration, press 'Apply' and after that press OK. It depends on the choosen configuration name if the 'Default' configuration stays selected or the new configuration is selected automatically. Ok, I have executed these steps and the .cproject file is broken. See attachment (id=113080). 1) Start eclipse (set workspace, don't check "Use this as default...", close 'Welcome' screen) 2) Menu: File->New->C Project 3) enter "myproject" as project name (Makefile project, -- Other Toolchain --), click Next, click Finish 4) click on 'myproject' at Project Explorer to set focus on it 5) Menu: Project->Properties --- now the dialog "Properties for myproject" is open 6) click on C/C++ Build --- the 'Default' configuration is selected at the drop down list (ok, its the only existing one) 7) click on "Manage Configurations..." 8) click on "New..." 9) enter "Rebuild" as configuration name 10) press OK to close "New.." dialog 11) press OK to close "Manage Configurations..." --- back at "Properties for myproject" dialog, note that the 'Default' configuration is still selected 12) select configuration "Rebuild" at drop down list 13) press 'Apply', note that a small window opens and closes immediatly 14) press 'OK', note that a small window opens and closes immediatly 15) exit eclipse by clicking the 'X', confirm by pressing 'OK' --- take a look at ".cproject", it will has a size about 30KB 16) open eclipse, confirm workspace 17) click on 'myproject' at Project Explorer to set focus on it 18) click on "Manage Configurations for current project" icon at toolbar --- you will see two 'Default' configurations, the .cproject file contains two 'Default' and one 'Rebuild' configuration
This bug was driving me mad but I was finally able to reproduce switching to my home desktop. Obviously my laptop works better, this bug just is not there - no matter how hard I try. Also reproducible on the head.
There are also other problems with saving configuration changes on Apply button. Try adding 2 new configurations inside Manage Configurations and select one of them before pressing Apply in C/C++ Build. Press Apply. Then press Cancel. The one selected is saved but the other is not. Any deletion is not saved on Apply either. It seems that fixing bug 233432 opened up some more darker corners in CDT to explore. I filed also bug 248341 - although unlikely that it is related.
It seems that not only me had problem of reproducing. See bug 239687 which was happily closed as "FIXED" as noted by Ali Burak Kulakli in eclipse.tools.cdt. I can reliably reproduce now even on my laptop. The key seems to be to select just created configuration before pressing Apply. At that point the new configuration gets created in project description. I can see that InternalXmlStorageElement gets copied from Default configuration along with its name. Not sure that it is really the cause but it definitely creates internal inconsistency in CConfigurationDescription object. Creating a new configuration from another one works in general.
(In reply to comment #12) > It seems that not only me had problem of reproducing. See bug 239687 which was Some more details. The .cproject file is wrong. The problem I have found is that there is a second configuration with the id in question. The first one is the correct configuration with the additional changes I made and the proper name. The second one is the default configuration with the default name. Perhaps because I copied the default configuration to make this new configuration??? The code in: CProjectDescriptionManager.java: createCfgStorages() adds to a Map based on the id. Since there is a second ICStorageElement with that id, the second put operation overwrites the correct ICStorageElement with the default one. A way to fix this (kludge???) is to look at the return value from Map.put() which will be null or the previous element (if one existed). If non-null and the element doesn't equal the new one we are just adding, put back the previous value (i.e. so first one wins). Map createCfgStorages(ICProjectDescription des) throws CoreException{ LinkedHashMap map = new LinkedHashMap(); ICStorageElement rootElement = des.getStorage(MODULE_ID, false); if(rootElement != null){ ICStorageElement children[] = rootElement.getChildren(); for(int i = 0; i < children.length; i++){ ICStorageElement el = children[i]; if(CONFIGURATION.equals(el.getName())){ String id = el.getAttribute(CConfigurationSpecSettings.ID); if(id != null) { ICStorageElement el2 = (ICStorageElement)map.put(id, el); if (el2 != null && el2 != el) map.put(id, el2); { } } } return map; } This fixes the problem for me and in fact, my new configuration comes back as the active one as it was active when I shut down Eclipse. I'll attach it as a patch as well for anyone who has commit rights to look at and try out.
Created attachment 114468 [details] Proposed patch to fix managed configurations problem.
The patch deals with already corrupted project. There are still 2 configurations with the name "Default" in cproject being created. I think it would be appropriate to address the cause of corruption in this task.
Created attachment 117245 [details] Proposed patch to fix managed configurations problem
(In reply to comment #15) > The patch deals with already corrupted project. There are still 2 > configurations with the name "Default" in cproject being created. I think it > would be appropriate to address the cause of corruption in this task. > I have posted a 2nd patch to prevent the corrupted .cproject. The problem occurs when a new configuration is added then selected prior to the apply button being pressed. What is occurring is that the new configuration has been added to a different CProjectDescription than the one being used during Apply. So, when a new configuration just added is selected and the Apply button is hit, the AbstractPage.performSave() method at one point calls its findCfg() method. The ICConfigurationDescription selected isn't known to the current ICProjectDescription so it creates one using ICProjectDescription.createConfiguration(id, name, base). There are two createConfiguration() methods for ICProjectDescription and the one currently used by findCfg() is used when cloning an existing configuration. I found that using this form results in the phantom configuration when the Ok button gets pressed. It ends up calling the CConfigurationDescription constructor form which has: CConfigurationSpecSettings baseSettings = ((CConfigurationDescription)base).getSpecSettings(); InternalXmlStorageElement baseRootEl = (InternalXmlStorageElement)baseSettings.getRootStorageElement(); InternalXmlStorageElement newRootEl = CProjectDescriptionManager.getInstance().copyConfigurationElement(baseRootEl, id, false); My patch adds a check to see if the ICConfigurationDescription id in question is known to the cached CProjectDescription of the CDTPropertyManager. If this is the case, it uses the 2nd form of createConfiguration() that takes ICConfigurationData and a build system id. The build system id is found from the existing ICConfigurationDescription we found in the CDTPropertyManager's CProjectDescription. With this change, there is no phantom configuration created in the .cproject. I added a case where if the configuration is also not found in the CDTPropertyManager's CProjectDescription, then a default build system id is used. I do not know if this is a possible scenario or whether the default id would cause a problem. Please review and let me know if I have missed anything.
Created attachment 117285 [details] phantom configuration test case Your analysis coincides with my findings. I tested your patch and took a look at the code and AFAICS it works correctly (dodging the faulty call). Still, as yourself note, createConfiguration() method is not correct and can create phantom configuration under these conditions. Attached is a test case demonstrating that.
Created attachment 122216 [details] patch 1 Andrew, thanks for another good test! Jeff unfortunately this issues can't / shouldn't be fixed in the UI. It's a core problem. The issue, as you both pointed out, is that the CConfigurationDescription constructor duplicates and imports the new configuration into the wrong project description -- the prjdesc of the original configdesc rather than the requested project description. Attached is a patch for CDT 5 & 6 which should resolve this issue. I've added a new createStorage method to CProjectDescriptionManager (next to the other configuration storage creation method). This isn't the ideal place, though is consistent with the current CProjectDescriptionManager.createStorage(...) method. This should be re-examined in the context of bug252966. Andrew and Jeff I'd be interested if you guys have any further comments. Elena can you review?
(In reply to comment #19) > Created an attachment (id=122216) > patch 1 > > Andrew and Jeff I'd be interested if you guys have any further comments. No, I am satisfied with this one. Kudos to you James.
(In reply to comment #19) > Attached is a patch for CDT 5 & 6 which should resolve this issue. I am new to the Eclipse platform, but I encountered this same bug when setting up a C Make project with multiple configurations. I was wondering what steps I need to take to apply this patch to my installation of Eclipse. Ideally, I'd like to get an update so that I can point members of my team to a specific version, rather than having to do a custom build of the IDE. Can anyone share how I might do this, or if it's not yet available, when it might be? Many thanks in advance! ~Dave~
(In reply to comment #21) > I am new to the Eclipse platform, but I encountered this same bug when setting > up a C Make project with multiple configurations. I was wondering what steps I > need to take to apply this patch to my installation of Eclipse. Ideally, I'd > like to get an update so that I can point members of my team to a specific > version, rather than having to do a custom build of the IDE. Can anyone share > how I might do this, or if it's not yet available, when it might be? Many > thanks in advance! The patch isn't yet applied to HEAD. You should take a look at the FAQs: http://wiki.eclipse.org/CDT/User/FAQ#How_do_I_build_CDT_from_CVS_if_I_want_an_even_more_recent_build_and_I_want_all_the_pieces_and_parts.3F Having checked out the source, there's an Apply Patch method on Team pop-up menu. You can then export the updated plugin from the workspace. If you need more info the Plugin developers guide should point you in the right direction and/or ask on the newsgroup: news://news.eclipse.org/eclipse.tools.cdt
patches (4 and 5) applied on 5.0.2 and head, thanks James and Andrew
Hi, Thanks for applying the patch to the 5.0.2 tree. When can we expect a 5.0.2 release of CDT? I searched for a release roadmap, but to no avail... Thanks, Dave
It will be sometime in February, in the meanwhile you can download nightly build
I would like to add just one more thing to the bug description. If you create a new configuration and you also have environment variables this is what happens depending which buttons you press (CDT version 5.01): OK: Configuration is properly saved in .cproject Environment is NOT saved to .settings/org.eclipse.cdt.core.prefs Apply & OK: Extra Default configuration is added at the end of .cproject (corrupt file) Environment is correctly saved to .settings/org.eclipse.cdt.core.prefs Apply & Cancel Configuration is properly saved in .cproject Environment is correctly saved to .settings/org.eclipse.cdt.core.prefs So the Apply and Cancel combination is the only one that works correctly. I did not apply the patch so I do not know if the patch solves the problem with saving the settings in .settings/org.eclipse.cdt.core.prefs.
(In reply to comment #26) > OK: > Configuration is properly saved in .cproject > Environment is NOT saved to .settings/org.eclipse.cdt.core.prefs I've created bug 265282 to track this. I don't think it's related to this issue of persisting the configuration more than once in the project description.
