Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [cdt-dev] Excluding included files / directories from the indexer scan

Hello Thomas,

> I think that this is the wrong approach to this problem.  I think that
we

Possibly, thanks for suggestions about how to do things "the CDT way".
My suggestion was based on two problems  which may need different
solutions. Let me tell you more ...

> ever been before.  This means that external databases (I know that QNX
> has one, RedHat had one, apparently Norbert has one too) that provide

Good guess, we actually have html-based help for our API and I would
like to use this "database" because it can also give a description of
the function. This is my "problem a".

> information should be unioning (as opposed to appending) their
information.

This would solve "problem a". Is it already addressed by an enhancemant
request?

Now here is the story of my "problem b":

******story starts*********
Once upon a time a homegrown operating system kernel and some
applications were written, using a compiler which evaluates parameters
on the stack "right to left". Everybody was happy until the compiler
manufacturer decided to discontinue it's support.

Now the kernel was pretty much stable and was not ported to another
compiler. But for the applications it was decided to move to the gnu
compiler which evaluates "left to right". In order to make everything
work together with a minimal change of source code the system headers
were modified according to the following scheme for every system
function that was callable from an application:

#if defined(__GNUC__)
#define func(par1, par2, par3)  func((par3), (par2), (par1))
#endif
void func(char* example1, int example2, double example3);

So if sources were compiled with gcc the order of parameters would be
switched implicitly and application and kernel could talk to each other
without modifiying the implementation code of either.
******story ends*********

Back to eclipse: When I to "content assist" for func I get to see three
entries:

- One from my help provider (which I like)
- One for the #define (which I don't like)
- One for the function definition (which is misleading because it shows
parameters in reversed order from the standpoint of the application
programmer).

Hence my idea to simply find a mechanism to exclude the header file from
content assist. I wonder whether your idea 

> information should be unioning (as opposed to appending) their
information.

would solve even this scenario. It would work only in a "C" environment
when a function supplied from an ICHelpProvider would take precedence
over suggestions from the indexer.
In "C++" it would have to be assumed that the same function name with
two different parameter lists would be two variants of an overloaded
function. Hmmmm...

OK, this was a lot of text and thanks for reading through all this. I
feel that you have to know the whole story in order to understand the
question fully. And I still welcome suggestion about how to solve this
"the CDT way".

Thanks,


Norbert


Back to the top