Re: [cdt-dev] Re: Hyperlink Navigation for 2.0 moved to cdt-dev

["Alain Magloire" <alain@xxxxxxx>]

> > > 
> > 
> > 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.
> 
> I don't think that this makes sense regarding relative include paths. ANSI 
> spec indicates that relative inclusions are relative to the file being 
> compiled at a given time, not to the project as a whole.  While inclusion 
> paths & CPathEntry are captured in the UI on the project granularity, they 
> really are specific to the individual resource. 
> 

Not following.  IIncludeEntry from c path can be set for individual resource,
allowing to set an include path for a specific IFile.  Include entries set on
a Container(IFolder, IProject) affects the children, unless specify otherwise.

The draft in cdt-core-home/doc/cpathentry.html, unfortunately, did not make this
clear,  ... on my TODO least to remedy.

> My fear is that going along this path would make for some "unbuildable" 
> managed make projects by default.  IMO, projects are just a logical 
> abstraction of the grouping of files as it is convenient for the user (due 
> to similarities in how they are laid out, toolchain, built, or any other 
> reason) and it is difficult (and potentially dangerous) for us to put too 
> many semantics into the project concept. 
> 

I admit not following your thoughts here.
The idea behind the C path management is the same as the classpath management behind JDT.