Community
Participate
Working Groups
Reproduce (I've reproduced it with 'master'): * Create new "Hello World ANSI C project" * Make a copy of the generated .cproject file (name it .project.1) * Change one toolchain tool option setting. It must be one that adds a "<option>" entry in .cproject which was previously not there. E.g. "Project" -> "Properties" -> "C/C++ Build" -> "Settings" -> "Debugging": Enable "Generate prof information (-g)" * Make a copy of the modified .cproject file (name it .cproject.2) * Compare .cproject.1 and .cproject.2: You notice a new <option ...> tag. Please note that the "name" attribute is not there * Change the value of another toolchain setting. This time, it doesn't matter which one - just not the one you changed above * Make a copy of the modified .cproject file (name it .cproject.3) * Compare .cproject.2 and .cproject.3: You notice two things: 1) The "value" attribute of the latter changed tool option was adjusted (that's ok of course) 2) The "name" attribute of the former changed option appeared (that's probably ok - but it should better have been there already before) => The problem is that in the first place, the "name" attribute is missing. While I don't know whether this causes any real issues with standard CDT, it causes issues with one of our plugins we are using in our CDT based product, as this leads to project setting changes (.cproject) at unexpected points in time. The problem seems to be in HoldsOptions.getOptionToSet(...), which is created when the tool option is initially created: The new tool option is created based on its "tool option superclass", but without passing a "name" to the createOption function. it's unobvious to me why it has been implemented like that. According to my investigation, that code is there like this since "2f7eba12 (Leo Treggiari 2006-03-03 19:19:47 +0000 562)". Isn't is as easy as passing newSuperClass.getName()? Btw: The option name reappears in .cproject.2 because the properties dialog creates a copy of the configuration (and thereby of all options) during the second option value change. The important point is that tese copies are not created by HoldsOptions.getOptionToSet(...), but by HoldsOptions.copyChildren(...) which has some logic to get the name attribute out from the option (or the options superclass) from which the copy is genereated.
