Re: [cdt-patch] Removed the ReferenceBlock from the Project Prope

["Alain Magloire" <alain@xxxxxxx>]

> 
> > -----Original Message-----
> > From: Alain Magloire [mailto:alain@xxxxxxx]
> > Sent: Thursday, October 31, 2002 3:39 PM
> > To: cdt-patch@xxxxxxxxxxx
> > Subject: Re: [cdt-patch] Removed the ReferenceBlock from the Project
> > Properties display
> > 
> > > 
> > 
> > Bonjour
> > 
> > I'm not sure I follow the rationale of this patch.
> > 
> > We do basically the same thing as JDT(Properties -> "Java Build Path")
> > where you have Reference Project filter on nature(Java Nature).
> > 
> > Those projects(when selected) are required for a build.
> 
> Java has the same User issue.
> 
> >From a usability standpoint ...
> One problem is that there is no synchronization between the 
> Project properties -> Referenced Projects (filtered on nature) 
> and 
> Referenced Projects (unfiltered)
> 
> When the properties are first opened both pages will show the same
> references (read from the project)
> 
> If you select and deselect references on either page, the changes are not
> reflected
> in the other page.
> 
> When you close and save the changes, it is not obvious what is going to
> happen. 
> Some selections remain selected when you had deselected them and other are
> deselected when you selected them.
> 
> In addition, it is not obvious as to which view has precedence of over the
> changes.
> 
> 
> So I guess the question(s) is/are
> 
> 1) How does the referencing differ in either view. 
>    They both read the same information and just filter what is shown.
> 2) If they are different why does a selection in one view, 
>    show up in the other the next time the properties are opened.
> 3) How does this affect the build? Since the user can at any time reference
> any 
>    projects that are in the workspace?
> 

In my mind, it should have been the other way around, the default (unfiltered)
propety that the workbench adds by default is undesirable.

For example, if you have a QNX Project (Binary format is ELF), the builder will
try to find libraries, source files, include files etc .. on "compatible" projects(lets not
call them referenced yet).  It offers you a list of those "compatible"
projects in the Property page.

The same for JDT, where the information is actually save in the .classpath file.
It needs this for the build(setting CLASSPATH etc ..) and it is not necessarly tied
to the the workspace "referenced projects".

For the JDT, in Eclipse-1.0, it was not trying to do any tie to the workspace
"referenced" projects i.e. setting one does not mean the other is updated(only
the .classpath in JDT).

The project provides a list of what it thinks are compatible list of projects
that it can use, for example QNX projects will only provide a list of projects
who are ELF binary formats and QNX nature.  JDT may provide a list of projects
to set the CLASSPATH if they have a JDT builder etc ..  And the information
is not necessary save in the worksapec "referenced projects" but rather in
.classpath.  And the QNX Project may decide to save the information in the
is own Makefile(common.mk), which it does by the way.

The default CDT just reused the facility provided by the workspace (referenced projects)
to save the info, but it should save the information for example in the Makefile once
the new builder is ready.

I know ... confusing 8-)