Re: [cdt-patch] Hyperlink Navigation for 2.0

["Alain Magloire" <alain@xxxxxxx>]

> 
> When you say dependencies, do you mean  project references? If yes, then 
> I'm not sure if this 
> is correct. I always thought that Project A referencing Project B means 
> that Project B's build output
> is a prerequsite for building Project A...and that's all. Any Project B 
> include file paths that are used 
> by Project A still need to be entered in Project A.
> 

Why ?
Think of the JDT, when you go in the property of the project
and add a reference to another project, its .classpath is also exported
meaning the jars/bin/projects (not sure about the variables) etc ...
For example, this is use in the case of binary projects by PDE

In C/C++ more information needs to be exported, libs, includes paths etc ..

This is important for integration, with third parties libraries.

> > IMHO, there is a flaw in IScannerInfo since it does not allow to 
> > make a distinction between
> > include paths system/compiler builtins and contribution on the 
> > command lines(-I ..) , it makes a difference when doing
> > this, (We address this in the ICPathEntry):
> > 
> > #include <stdio.h>
> > 
> > #include "stdio.h"
> > 
> > Suggestion:
> > 
> > - Search include paths(including dependent projects)
> > - Fall back to search recursively the project.
> 
> By always searching the include paths first, you could be finding the 
> wrong file. What if you have #include "foo.h"?

It matches the behaviour of the build, to have different behaviour
for each module is confusing.  Compilers/builders search files in
the include paths given (depending on #include <..> or "").

That can lead to situation, where I have open an include via (Open Include action)
change/edit it and build the wrong executables ... meaning I've been editing the
wrong header not the one found by the builder.  Those bugs are annoying and
hard to find.  I suggest we follow the same behaviour of the builder.

> The parser first tries to search for "foo.h" locally before trying to find 
> it on the include paths. We would currently look for it

Yes, "foo.h" is different, the current directory need to be search first
then the include paths(including the builtins include paths).

> amongst the include paths and quit if we found it in one of the 
> directories - even if it's not the one that is actually being used.
> 
> I can redo the Action to take into account what type of include is used - 
> ie. mimic what the parser actually does. If it's #include "foo.h", I'll 
> look locally and then, if not found, I'll look on the include paths. If 
> it's #include <foo.h>, I'll look solely on the include paths. This way, if 
> the user chooses to open the file they'll get the file actually used by 
> the parser. What do you think?
> 

Agreed.  There is a IInclude.isStandard() for this purpose do not think
it was implemented.

> >
> > I do not quite follow, this:
> >    ii) Search project regardless of what was 
> > Why ? if you already find a match.
> 
> I changed it so that if more than one file is found amongst the include 
> paths/project, the user can say which one he really wants. I thought that 
> since we're not giving truly accurate results, we might as well give them 
> all the results.
> 

Behaviour like fall back to recursively search the project or given them multiple choices,
my opinion is, this is potentially confusing.
The user thinks every thing is OK, since CDT can find the header somehow
But he/she is puzzle on why the build consistently fails.

My point is to be consistent:
- the Action should be consistent with the way the parser find the headers and
  the parser should be consistent with the way the build indicates include paths.
- A project in the build can also "export" its include paths, see (ICPathEnty drafts)
  or JDT classpath mechanism.