Community
Participate
Working Groups
Build ID: I20080617-2000 Steps To Reproduce: 1. Create a new C/C++ project of any flavor 2. Create a new Build Configuration, lets call it Fooo, copying from either Release or Build (irrelevant) 3. Project -> Properties -> C/C++ Build 4. Select "Settings" node under "C/C++ Build". 5. Note presence of "Tool Settings" tab. 6. Return to top-level "C/C++ Build" node 7. Unselect "Generate Makefiles automatically" 8. Return to "Settings" node 9. Note lack of "Tool Settings" tab. More information: This is quite easy to reproduce. It looks intentional, but is broken in two ways: 1. If you have access the "Settings" node with a configuration selected that DOES automatically generate makefiles, the "Tool Settings" tab will remain available *EVEN IF* you choose a different build configuration from the drop-down "Configuration:" at the top of the "Settings" page. You can then apply the changes to this configuration, even though it (apparently) shouldn't allow such things. 2. The indexer honors the settings made through the mechanism just described in (1). Stunningly, abuse of the mechanism described in (1) is the ONLY WAY to get the indexer to look into different directories when using anything other than "Generate Makefiles automatically". This is extremely annoying to me and highly confusing to others I have tried to explain it to. I work for a company with a custom build system and I invoke their build system in order to perform a build. The include paths unsurprisingly live in a symlink farm that contains thousands of entries. I do not want CDT to generate Makefiles for me - I just want the indexer to honor my settings for the include path so that source navigation works properly, etceteras. In order to get the indexer to honor my settings I have to let CDT create makefiles for me, all of which are unnecessary in my case, in a directory of its choosing. This doesn't play particularly nicely with source control, although it is trivial to get around it with .[cvs|svn|p4]ignore files. Alternatively I can use the mechanism in (1) to "hack" the settings in without generating the cruft, but then making any changes is a pain (select Debug/Release as active build configuration again, preferences, settings, change configuration to my own, make changes, apply, go back to main workspace, set configuration back to my own, rebuild). I feel pretty justified in saying this is a broken behavior pattern, but I am open to other opinions. At the very least I expect to be able to configure the directories for the include path of the indexer without having to give Eclipse control over my makefiles. On a purely different note, the fact that many of the settings simply VANISH (without so much as a dialog box) is extremely unintuitive. I was writing a wiki doc explaining to my teammates how to achieve CDT nirvana when I realized all of a sudden that I couldn't follow my own steps. It was only when I went back and discovered this strange behavior that I realized I had been wasting my time for the previous hour because I unmarked a checkbox that didn't tell me it was about to *hide* (not just disable!) 75-80% of my settings panels. No wonder I couldn't find them any more, they were gone! To end on a positive note, barring the silly workaround and ridiculous confusion factor, CDT has made tremendous improvements since the last time I used it, enough that I am willing to live with these kinds of quasi-minor issues to use it. Thanks very much for your continued work on this project!
