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

[John Camelon <jcamelon@xxxxxxxxxx>]

Moving to the dev list ... 

cdt-patch-admin@xxxxxxxxxxx wrote on 12/09/2003 11:06:49 AM:
> > 
> > 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.

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. 

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. 

JohnC