| Trouble with CDT GCC Build Output Parser [message #1044151] |
Thu, 18 April 2013 14:52  |
 Philip Keller
Messages: 5
Registered: April 2013 |
Junior Member |
|
|
Hi,
I've just started using the new discovery methods in CDT 8.1.2 / Eclipse Juno. My project is pretty simple, but I'm still managing to have trouble with the indexing.
I have a Makefile Project using a Cross GCC toolchain. In Project Properties > C/C++ General > Preprocessor Include Paths, Macros, etc. > Providers, I've chosen two parsers, in this order:
- CDT GCC Build Output Parser:
- Store entries in project settings (so others get the same settings from the version control system)
- Compiler command pattern: "(h8300-elf-ecos2kpit h8300-elf-gcc)" (our compilation command)
- Container to keep discovered entries: File (-D settings vary from file to file)
- Use heuristics to resolve paths (why not)
- CDT GCC Built-in Compiler Settings
- Store entries in project settings (same reason as before)
- Command to get compiler specs: h8300-elf-gcc -E -P -v -dD ${INPUTS}
After applying these changes, in Preprocessor Include Paths... > Entries, I see the two selected parsers. There's an expansion triangle next to the Built-in Compiler Settings, but not next to the Build Output Parser. First question: Does this mean the Build Output Parser is not working? Can I get the Build Output Parser to produce a log file?
I then do an Index > Rebuild and Index > Search for Unresolved Includes. I don't understand what I'm seeing: for include directories known via the Build Output Parser, some include files have been resolved, some not. Second question: so is the Build Output Parser working or not? Why some files and not others?
Thanks in advance for any help.
-- Phil
|
|
|
|
| Re: Trouble with CDT GCC Build Output Parser [message #1044760 is a reply to message #1044311] |
Fri, 19 April 2013 09:56  |
Philip Keller
Messages: 5
Registered: April 2013 |
Junior Member |
|
|
Andrew, thanks for helping ignoramus users like myself.
To answer the obvious questions: yes I do a build, and yes there are -I's and -D's to parse. Thanks for the pointer concerning the "wrench" decorations; now I'm finally beginning to understand what ".settings/language.settings.xml" is all about. Your explanation deserves to be in the Help files.
Using the file Properties information, it looks like the Build Output Parser is doing its job; so apparently I'm skunking the Indexer. An example:
- <C++ source file> has code analysis error, that <some symbol> could not be resolved
- <some symbol> is defined in <system directory>/<some sub-directory>/<some include file>
- Properties of <C++ source file> shows that <system directory> was found by the Build Output Parser
- <C++ source file> #includes its <class interface definition> (indexed OK), which includes another class' interface (indexed OK), which #includes <some sub-directory>/<some include file>
- CODAN flags that last #include as "unresolved inclusion"
- When I copy the "#include <some sub-directory>/<some include file>" statement into <C++ source file> or <class interface definition>, the problem goes away.
- I tried increasing the Indexer's cache limits, but that made no difference.
- I forgot to mention: in the "Includes" node of the project browser, I only have entries relating to the Built-in Compiler Settings, nothing rooted at the directories found by the Build Output Parser.
- And yet, most #includes can be opened from within the source (F3). ???
So I know this is getting off the original topic, but do you have any idea why this might be happening?
-- Phil
[Updated on: Sat, 20 April 2013 07:39] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.03245 seconds
] 
Search
Help
Register
Login
Home
