Re: [cdt-patch] Outline Open Include patch

["Thomas Fletcher" <thomasf@xxxxxxx>]

Alain Magloire <alain@xxxxxxx> said:

[ Discussion on the downfalls of a particular patch snipped ]
> 
> The ease of use that you advocating may cause more problems then good.
> For example, duplication of files.  The indexer/parser picks the wrong
> header, screwing up the content assist.
> 
> How about to make it consistent for all the clients of
> the IScannerInfoProvider.  Meaning, for example in the case of
> the Standard Make Project, which implements IScannerInfoProvider, make
> it a property (Checkbox or something, or even the default) to 
> recursively search the entire projects and maybe reference 
> project(the header could be in library reference project).
> 
> So when we(indexer, search, parser, outline/openinclude, ...) ask the
> provider for include paths for a particular resource, it will be up 
> to it to make the policy call.

[Pseudo code snipped]
 
> Everybody gets the same response,  and the behaviour could be turn off,
> by the user.
> 
> Now, that is a _lot_ of change, not sure if it belongs to 1.2 branch.

I would certainly buy into that in a large way.  Brings us the consistancy
we want as well as providing a common point to implement some additional
flexibility.  The fact that we are currently patching and fixing pieces 
here and there has always bothered me.

Now obviously this won't fly for 1.2, but it should be something we can 
look at for 2.0 I would think.  Then any "missing or broken" components
can be "fixed" to use this new piece (including the debugger for its
source lookups I imagine). 

Something also came to a discussion with an end user of the CDT today.
Their project of course contains: Neutrino, VxWorks and Windows source
all in one tree.  For them a "single" configuration (in this case the
configuration I'm talking about is the Include/Defines for source code
navigation) isn't desirable, they would need to have multiple configurations
and the ability to switch between them.

Now in a Managed Make scenario ... this would start corresponding to the
concept of toolchains, but there is no such mechanism for the "Standard
Make".  I think that this should be something that we take into 
consideration.

I would also like to mimic the Metrowerks mechanism of loading preferences
from a C like header file:

#define X
#define Y 5
#include "a/b/c"
#include "{project_root}/...}

Would such a patch be of interest?

Thanks,
 Thomas ... feeling up to the challenge!