Bug 363203 - Indexer doesn't work when adding workspace relative includes to projects not stored in the default location
Summary: Indexer doesn't work when adding workspace relative includes to projects not ...
Status: REOPENED
Alias: None
Product: CDT
Classification: Tools
Component: cdt-build (show other bugs)
Version: 8.1.0   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: cdt-build-inbox@eclipse.org CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-08 11:54 EST by Josh Davidson CLA
Modified: 2020-09-04 15:26 EDT (History)
3 users (show)

See Also:


Attachments
Screenshot (476.92 KB, image/png)
2011-11-08 11:54 EST, Josh Davidson CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Josh Davidson CLA 2011-11-08 11:54:19 EST
Created attachment 206610 [details]
Screenshot

Eclipse IDE for C/C++ Developers

Version: Indigo Service Release 1
Build id: 20110916-0149

"Builder configuration for the indexer" is set to "Use active build configuration"

My workspace includes a project "Simics" that is not stored in the workspace, or "default" directory.  Instead, the project is stored somewhere else on my hard drive.  This seems to break the indexer when I add workspace relative include paths.  As you can see in the screenshot below, everything is configured correctly and builds, but the indexer seems to assume that /Simics is directly under my workspace directory instead of using the actual project configuration.

Since the internal builder is smart enough to replace <workspace_loc> with the actual root directory of the "Simics" project, the indexer should be as well.
Comment 1 Josh Davidson CLA 2011-11-08 12:18:45 EST
(In reply to comment #0)
> Created attachment 206610 [details]
> Screenshot
> 
> Eclipse IDE for C/C++ Developers
> 
> Version: Indigo Service Release 1
> Build id: 20110916-0149
> 
> "Builder configuration for the indexer" is set to "Use active build
> configuration"
> 
> My workspace includes a project "Simics" that is not stored in the workspace,
> or "default" directory.  Instead, the project is stored somewhere else on my
> hard drive.  This seems to break the indexer when I add workspace relative
> include paths.  As you can see in the screenshot below, everything is
> configured correctly and builds, but the indexer seems to assume that /Simics
> is directly under my workspace directory instead of using the actual project
> configuration.
> 
> Since the internal builder is smart enough to replace <workspace_loc> with the
> actual root directory of the "Simics" project, the indexer should be as well.

Well after leaving Eclipse running for nearly an hour, the indexer did pick up those headers.  Very strange.  Previously, I had refreshed the workspace and rebuilt the index multiple times in conjunction with closing and opening both the source file and Eclipse, but nothing worked.
Comment 2 Markus Schorn CLA 2011-11-25 05:10:37 EST
Translation of build configuration to absolute paths is done by the build system.
Comment 3 Andrew Gvozdev CLA 2011-11-25 10:04:08 EST
The translation is being done by build system correctly. I tested with non-default location of the project and it works fine.
Is it possible that in your setup the configuration being indexed (and presented in UI) is not Active (as it would be by default)? What configuration is specified in project preferences->Indexer->"Build Configuration for the indexer"?
Comment 4 Andrew Gvozdev CLA 2011-12-08 16:45:16 EST
No response from submitter, assuming it is the configuration problem.
Comment 5 Josh Davidson CLA 2011-12-21 15:42:33 EST
(In reply to comment #3)
> The translation is being done by build system correctly. I tested with
> non-default location of the project and it works fine.
> Is it possible that in your setup the configuration being indexed (and
> presented in UI) is not Active (as it would be by default)? What configuration
> is specified in project preferences->Indexer->"Build Configuration for the
> indexer"?

As I mentioned in the OP, it was set to to the active configuration.  Also, mentioned in my follow up that the indexer did start working after a long period of idle time, so I don't think this is a problem (at least not as framed in the OP).
Comment 6 Andrew Gvozdev CLA 2011-12-22 12:43:54 EST
(In reply to comment #5)
> As I mentioned in the OP, it was set to to the active configuration.  Also,
> mentioned in my follow up that the indexer did start working after a long period
> of idle time, so I don't think this is a problem (at least not as framed in the
> OP).
Sorry that I missed that in the description. Still, it is not a problem with relative includes.

But, Markus, I've seen issues like that myself when index get lost fully or partially on some unknown event - even if my projects do not use scanner discovery. It looks like there is a black hole between MBS and indexer where language settings get occasionally lost. Let me keep this task open.
Comment 7 Markus Schorn CLA 2011-12-23 03:49:33 EST
(In reply to comment #6)
> ...
> But, Markus, I've seen issues like that myself when index get lost fully or
> partially on some unknown event - even if my projects do not use scanner
> discovery. It looks like there is a black hole between MBS and indexer where
> language settings get occasionally lost. Let me keep this task open.

For the given issue it is not relevant whether the index is complete or not. The editor shows that the includes cannot be resolved. The most likely explanation for that is, that the include search path is not passed to the parser. Josh, to nail that down, please create a parser log for simics.c (in a situation where the includes are not resolved). You can create the log from the context menu of the file in the project explorer - Index - Create Parser Log.