Community
Participate
Working Groups
Using default indexer settings, and a project for creating Qt widgets, this situation arises: The original project has a header file (file A) that includes another header (file B) that doesn't yet exist. The build process generates the header (file B) into the project, but when the files that need to be indexed post build are calculated, the generated header is excluded and the file is not indexed.
The generated headers appear as unused headers. In order to have them indexed you can either rebuild the index or select the option 'index unused header files'. This can be done on workspace level (in the preferences) or per project (in the project properties). The underlying issue is that CDT does not make an attempt to re-index files when an included header has been changed (or added). This is similar to bug 171834
Thanks for your quick reply, Markus! Although changing the preference in then project does address the issue, this is is a bug because the header is not unused since it is included by a project source file. It seems like the indexer task should be checking whether this file is being included before disregarding it, right? (In reply to comment #1) > The generated headers appear as unused headers. In order to have them indexed > you can either rebuild the index or select the option 'index unused header > files'. This can be done on workspace level (in the preferences) or per project > (in the project properties). > > The underlying issue is that CDT does not make an attempt to re-index files > when an included header has been changed (or added). This is similar to bug > 171834
(In reply to comment #2) > Thanks for your quick reply, Markus! Although changing the preference in then > project does address the issue, this is is a bug because the header is not > unused since it is included by a project source file. It seems like the > indexer task should be checking whether this file is being included before > disregarding it, right? I don't claim that this is not a bug, it is similar to bug 171834. However, there is no simple fix for that: When indexing the sources, the file is not yet there, thus it cannot be included. When it is added (by the build) we'd actually have to look at all the sources again to see whether any one is picking up the new header.
(In reply to comment #3) > I don't claim that this is not a bug, it is similar to bug 171834. However, > there is no simple fix for that: > When indexing the sources, the file is not yet there, thus it cannot be > included. When it is added (by the build) we'd actually have to look at all the > sources again to see whether any one is picking up the new header. Maybe if the indexer tracked includes that couldn't be found separately, when it came across one again (say the project was fixed by the user or a file was generated by build) it could know to re-index the source files that included it.
(In reply to comment #4) > Maybe if the indexer tracked includes that couldn't be found separately, when > it came across one again (say the project was fixed by the user or a file was > generated by build) it could know to re-index the source files that included > it. Yes a solution would have to work along these lines. The index does store unresolved includes, however we don't have fast access to all unresolved includes for a given file name (that would list the candidates for re-indexing).
