Community
Participate
Working Groups
Build ID: 3.4.0 Using BuildID installed from Ganymeded update manager (200805231539). Also seems to be a problem in CDT 4. Steps To Reproduce: 1) Create HelloWorld C Project 2) Right click on hello.c > Properties 3) Add a Defined symbol foo 4) Press OK 5) Edit properties on the src directory 6) Add 'asdf' under includes 7) Press OK 8) View the Properties on hello.c and the list of included directory entries is blank. More information:
Created attachment 117543 [details] Test 1 Add a test to core.settings.model for the issue. Currently investigating this as it causes two problems for me: 1) I can't user can't modify a parent resource description and have the change picked up on the children 2) The entry duplication is causing very large in memory data trees
Created attachment 118281 [details] Test 2 A few more tests for this. It turns out not to be simple to implement. To make this work you need: - ICSettingEntries need to have a notion of being 'Unset' relative to their parent's (in the resource tree) resource configuration. - The Configuration data's need to persist this attribute with the language setting entries. - This is straightforward for the cdt.core CDefaultConfigurationData - However for the managed build BuildConfigurationData it is less so as the managed build setting entries already have the notion of undefined language settings. This, for example, allows the user to undefine a built-in preprocessor macro which has been inherited from some external settings provider / scanner discovery. This bug's notion of undefine is therefore slightly different -- it is undefined with respect to the parent resource in the resource hierarchy. In the managed build currently there is no notion of undefined if the given toolchain tool option doens't have an undefined Option. - With the above, it would work reasonably well for macros, but less well for include paths and other order dependent language entries. For these there would need to be support in the UI for showing 'locked' entries inherited from the parent resource configuration. With the ability to unlock and rearrange the include path search order. I still believe it would be worthwhile to have language settings automatically propogate to children (as other tool settings appear to do) - experimentation shows a large reduction in tree size (when there are many includes, macros and resource configs). However this becomes less straightforward on interfacing to the build system. Perhaps the ultimate solution would involve not keeping the xml tree around with the runtime configuration. If so the setting entries contents could be intern'd/cached saving lots of memory.
