Re: [cdt-patch] Outline Open Include patch

[Sean Evoy <sevoy@xxxxxxxxxx>]

Hi Thomas,
I just got dug-out from all my email,
so I thought I would weigh in on some of the points you have raised.

[Alain's proposal snipped]

> I would certainly buy into that in a large way.
 Brings us the consistency
> 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.

This is the same problem that comes
up again and again in different discussions. Namely, in the absence of
complete information/confidence about the project build settings (be they
includes paths or defined symbols), user-facing clients of this information
will experience failure. My concern is where we put the failure recovery
logic. Sure, some of it can be pushed into the IScannerInfoProvider, but
each build system provider will have to implement a "reasonable"
heuristic to deal with failure based on the option setting Alain proposed,
so I am not sure this guarantees a consistent end-user experience. Since
each client may have different levels of "tolerance" for failure,
the recovery logic may better reside in them. By this I mean that a user
may accept an partial list of content assist suggestions, but a search
with incomplete results could be misleading so let each client respond
appropriately (i.e content assist shows whatever has been contributed,
but search can do a more costly file-based search if the parse results
are bad).

> 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.

This is a pretty big addition to the
CDT since there is no concept of configuration and no way to switch between
them. Heck, even the configuration switcher in the managed make feature
is pretty clunky. If the customer is using a standard make project, then
configuration as you define it is really associated with the build target
in their makefile. I know that Vlad's proposal includes something about
handling the user switching make targets. Perhaps that will be sufficient
(or a be a starting point) for solving this for your customer. Personally,
I would like to see support for configurations in the Eclipse core rather
than a solution that depends on the build system for your project, but
that's probably a pipe-dream for now. 

> 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}/...}
> 

Is there an advantage to this approach
over, say, reserving a spot in the .cdtproject file for this information
and using CPathEntry and path variables? One of the problems that we have
to address in this release is what we want to do about specifying inter-project
dependencies. For example, what includes paths, libraries, and linker search
paths should be added to project A if it depends on project B. Would the
header file address this issue too, or do you see it as a repository for
just the "configuration" settings?  

This has been a very interesting thread.
Just what I needed to kick-start the rest of the week!

Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada