Community
Participate
Working Groups
Build Identifier: 20090920-1017 When I add a default listOptionValue under an includePath option, I can specify it as either 'builtIn' or not. I can also embed environmental variables with ${...} So if there are four possible types of includePaths: 1) builtIn with environment variables. 2) builtIn without environment variables (hardcoded path). 3) non-builtIn with environment variables. 4) non-builtIn without environment variables (hardcoded path). The Indexer seems to be able to find all header files in all 4 types of includePaths. However, when I try to actually open an included header file (right click on a #include <stdio.h>, click Open Declaration), it cannot resolve header files that in type 1 (builtIn includePaths with environment variables) Reproducible: Always Steps to Reproduce: 1. Create a new CDT toolchain 2. Create a tool with an includePath option 3. Add a listOptionValue for that value, add a path that contains an environment variable, and specify builtIn = true. 4. Include a header file in that path inside the source code, and try to open the header file.
Please create a parser log (context menu of file in project explorer - Index - Create Parser Log). At the beginning of the log you'll find the include search path that is passed to the indexer. What paths does it contain?
Project: HelloWorldCPP Index Version: 5439488 Build Configuration: Release File: file:/C:/Documents%20and%20Settings/test/workspace/HelloWorldCPP/main.cpp Context: file:/C:/Documents%20and%20Settings/test/workspace/HelloWorldCPP/main.cpp Language: GNU C++ Include Search Path (option -I): C:\Documents and Settings\test\workspace\HelloWorldCPP\${CROSS_ROOT}\i686-pc-linux-gnu\include\c++\4.4.1\ C:\Documents and Settings\test\workspace\HelloWorldCPP\${CROSS_ROOT}\i686-pc-linux-gnu\include\c++\4.4.1\i686-pc-linux-gnu\ C:\Documents and Settings\test\workspace\HelloWorldCPP\${CROSS_ROOT}\i686-pc-linux-gnu\include\c++\4.4.1\backward\ C:\Documents and Settings\test\workspace\HelloWorldCPP\${CROSS_ROOT}\lib\gcc\i686-pc-linux-gnu\4.4.1\include\ C:\Documents and Settings\test\workspace\HelloWorldCPP\${CROSS_ROOT}\lib\gcc\i686-pc-linux-gnu\4.4.1\include-fixed\ C:\Documents and Settings\test\workspace\HelloWorldCPP\${CROSS_ROOT}\i686-pc-linux-gnu\include\ C:\Documents and Settings\test\workspace\HelloWorldCPP\${CROSS_ROOT}\i686-pc-linux-gnu\libc\usr\include\ Local Include Search Path (option -iquote): Preincluded files (option -include): Preincluded macro files (option -imacros): Macro definitions (option -D): Macro definitions (from configuration + headers in index): __builtin_constant_p(exp)=0 __builtin_offsetof(T,m)=(reinterpret_cast <size_t>(&reinterpret_cast <const volatile char &>(static_cast<T*> (0)->m))) __builtin_types_compatible_p(x,y)=__builtin_types_compatible_p(sizeof(x),sizeof(y)) __builtin_va_arg(ap,type)=*(type *)ap __CDT_PARSER__=1 __complex__=_Complex __cplusplus=1 __DATE__="May 19 2010" __extension__= __FILE__="file" __imag__=(int) __LINE__=1 __null=0 __offsetof__(x)=(x) __real__=(int) __stdcall= __STDC__=1 __thread= __TIME__="11:42:00" Macro definitions (from files actually parsed): Unresolved includes (from headers in index): Scanner problems: Unresolved inclusion: <stdio.h> in file: C:\Documents and Settings\test\workspace\HelloWorldCPP\main.cpp:8 Parser problems: Unresolved names: Exceptions in name resolution:
$(CROSS_ROOT) is defined as an absolute path containing cross compiler files. However, as seen from above, include paths that are 'builtIn' cannot resolve environment variables correctly. From what I've noticed in the Eclipse code, there are two flags for each includePath object - BUILTIN and RESOLVED, however if it was marked as BUILTIN it was always also marked RESOLVED, which means it never got a chance to resolve environment variables, I assume.
I guessed the version of CDT you are using (6.0.1), is that correct? The scanner info provider does not expand the variables, reassigning component.
how do I check the CDT version?
hi, any updates? Thanks.
This sounds like an issue in MBS. As you're using build option values, I'd guees the variables aren't being expanded before being handed back to core as setting entries. Can you provide instructions to reproduce this using stock cdt with a helloworld project, say?
Not sure what you mean by stock CDT? This only happens when I have a include path contain environment variables that's declared as built-in, thus I can't reproduce by creating a new project. I only ran into this because I'm create a new toolchain that explicitly defines default built-in include paths for gcc compiler for indexing purposes.
Ah, OK. I meant easy instructions to reproduce in CDT out the box. You best bet for fixing this is digging a bit deeper into managed build and debugging how the built-in paths are contributed.
(In reply to comment #8) > Not sure what you mean by stock CDT? > This only happens when I have a include path contain environment variables > that's declared as built-in, thus I can't reproduce by creating a new project. You can attach to the bug a small sample plugin defining a toolchain like that. Then we can reproduce by creating a new project.
