Hi Mike,
You can provide –D options to force one or the other variant, or you can provide c/c++ files that make exemplary usage of the headers.
I do not think it is worth looking into automatically indexing all possible variants because typically out of the possible variants just a few would be used
in reality.
Markus.
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Mike Kucera
Sent: Friday, September 14, 2012 8:03 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] pre-built index fragments and header variants
Hi Markus, thanks for the help.
It sounds to me like pre-built fragment would only contain multiple variants when a header is included by another header.
What if I had a pre-built index consisting of only this header file:
<header.h>
#ifdef M
int foo(int);
#else
int bar(int);
#endif
Then the user's project has two source files:
<source1.c>
#define M
#include "header.h"
int main() { foo(4); }
<source2.c>
#include "header.h"
int main() { bar(0); }
Assuming M was not defined at the time the pre-built index was generated, would I be able to navigate from the call to foo in source1.c to the header? It seems to me that the information on how
"header.h" is included is not available at the time the pre-built index is created. During generation of the pre-built index is there a way I can tell the indexer to index multiple variants without having a file that includes them?
"Schorn,
Markus" ---09/13/2012 11:40:25 PM---Hi Mike, A pre-built index fragment can contain multiple variants of header files just like the proj
From:
"Schorn, Markus" <Markus.Schorn@xxxxxxxxxxxxx>
To:
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date:
09/13/2012 11:40 PM
Subject:
Re: [cdt-dev] pre-built index fragments and header variants
Sent by:
cdt-dev-bounces@xxxxxxxxxxx
Hi Mike,
A pre-built index fragment can contain multiple variants of header files just like the project’s PDOM. Multiple variants are triggered by including a header that does not have an
include guard with significantly different macro-dictionaries. It does not matter whether the inclusion is made in a source or a header file.
A binding in an index fragment is never duplicated, the occurrences (declarations, definitions and references) can be. However, due to the ability to combine multiple fragments
we had to deal with such duplications for a long time.
It is possible to find all variants of a header (indirectly) included by the file of the editor. This is also true when the headers were picked up from a read-only fragment. However,
when performing F3 navigation, we do not use this kind of information for selecting the variant of the header shown in the editor.
Markus.
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Mike Kucera
Sent: Thursday, September 13, 2012 11:16 PM
To: CDT General developers list.
Subject: [cdt-dev] pre-built index fragments and header variants
Hi guys, Its been a while since I posted here. I have some tough questions for the index experts...
Is it possible to generate a pre-built read-only index fragment that includes multiple variants of certain header files? I would be indexing just a set of header files, so there wouldn't actually be any source files including the headers at the time that the
fragment is generated.
If a header is indexed more than once in the same linkage then how are duplicate bindings/names handled? If you did a general text search wouldn't the index potentially return duplicate bindings or names from each variant?
Normally if you navigate (F3) from a source file to a header I'm assuming the index knows in which variant to find the declaration/definition because the include relationship and significant macros are stored in the index. But, if the headers are in a separate
read-only fragment then how would it know which variant to use?
Thanks in advance.
|

|
Mike Kucera
|

|

|
Rational Developer for Power
|

|
Performance Advisor UI Team Lead
|

|
IBM Toronto Lab
|

|

|
mkucera@xxxxxxxxxx
|

|

|

|

|
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev