Community
Participate
Working Groups
It seems that "Add include Directory" can only add "system" (#include <x.h>) or "local" (#include "x.h") paths. However gcc -I option affects both #include "x.h" and #include <x.h>. When adding include paths there should be setting corresponding -I option, and this needs to be default setting.
Actually, checkbox "Contains system headers" is misleading. When it is selected the path already applies to both #include <x.h> and #include "x.h". It looks that in CDT ICSettingEntry.LOCAL maps to GCC option -iquote (applied to #include "x.h"), and absence of the flag maps to option -I (applied to both). The absence of the flag does not mean system-only. I think we should flip checkbox and name it something like: [ ] Apply to header files in quotes only (#include "file.h") Sergey, what do you think?
(In reply to Andrew Gvozdev from comment #1) > Actually, checkbox "Contains system headers" is misleading. When it is > selected the path already applies to both #include <x.h> and #include "x.h". > It looks that in CDT ICSettingEntry.LOCAL maps to GCC option -iquote > (applied to #include "x.h"), and absence of the flag maps to option -I > (applied to both). The absence of the flag does not mean system-only. > I think we should flip checkbox and name it something like: > [ ] Apply to header files in quotes only (#include "file.h") > > Sergey, what do you think? The problem goes deeper than just naming of the check box. CDT supports two types of include directory entries, the one that allows quoted and angle bracket includes and the one (ICSettingEntry.LOCAL) that allows quoted includes only. The two include directory types supported by CDT correspond to GCC flags -I and -iquote respectively. There is no way to tell CDT that an include directory can be used for angle bracket includes only, similar to -isystem option of GCC. "Add Include" and "Organize Includes" commands use the type of include directory to decide whether to use angle brackets or quotes. For lack of a better signal they use angle brackets for headers that are resolved relative to include directories that don't have ICSettingEntry.LOCAL. In many cases this is inappropriate. We are currently working around this problem by adding some of the include directories twice, once with ICSettingEntry.LOCAL and once without. This satisfies both, the include resolver and "Add Include"/"Organize Includes", but is ugly. A better solution would be to introduce the third type of include directory entries, ICSettingEntry.SYSTEM, corresponding to -isystem. This would require introduction of IScannerInfo2 (or IExtendedScannerInfo2) interface to add the getSystemIncludePath() method. The "Add include Directory" dialog could then contain two check boxes: [ ] For system header files (#include <file>) [ ] For regular header files (#include "file") At least one of the two check boxes has to be checked for the OK button to be enabled. Internally, the case of both check boxes checked can be represented as an ICSettingEntry without ICSettingEntry.LOCAL or ICSettingEntry.SYSTEM for backward compatibility. Andrew, what is your opinion of this proposal?
Your proposal sounds good to me. And it should be straightforward to implement.
