Re: [cdt-dev] About project properties.

[Sean Evoy <sevoy@xxxxxxxxxx>]

Thanks Alex,
That's actually not a bad idea. When
you add the QNX nature, do you remove the CBuilder from the project's build
spec to avoid the old builder getting called? I ask because if I use the
builder as a discriminator and other build systems leave it lying around,
then I have to test that it is the ONLY builder associated with the project.
Anyway, going forward I think we need to rework this whole properties page
thing anyway. I just don't think it will happen for 1.2.

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

"Alex Chapiro" <achapiro@xxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx

07/07/2003 04:15 PM

Please respond to
cdt-dev@xxxxxxxxxxx

To	<cdt-dev@xxxxxxxxxxx>
cc
Subject	Re: [cdt-dev] About project properties.

I know what you mean. QNX project just uses
 two natures: CNature and QNXNature. But I guess that such a properties
as those we are talking about are not nature-dependent but builder-dependent.
Why don't you check .cdtproject file for declared builder and display these
properties according to found builders? CNature seems to me too common
thing to serve as a builder discriminator.
 
Alex Chapiro
----- Original Message ----- 
From: Sean
Evoy 
To: cdt-dev@xxxxxxxxxxx

Sent: Monday, July 07, 2003 3:47 PM
Subject: Re: [cdt-dev] About project properties.


Crud, 
This is what I was worried about. 

Basically, anything is possible with sufficient information. I create the
tab in the Standard Make C/C++ Project wizard ()which shouldn't effect
you) and on the property page for projects with CNatures. From your comment,
I take it that QNX is supplying their own project creation wizards and
property pages. Are you using a QNX-specific nature to get your property
page to appear in the list? Does that nature have a requires-nature relationship
to the CNature or CCNature? If it does, then the standard project property
page gets displayed. I would prefer not to have to do some kludge to check
if some other build system is around because what if that build system
has decided it wants to use the standard build model to manage that info?

The current property page for projects with C or CCNatures is a bit confused.
 We mix up stuff that is related to a build (like the location for
the make utility, what to do in the face of build failure, and the path/symbol
information) with stuff that has little to do with build, like which parser
or indexer to use. Then, there's a lonely, orphaned task tags page that
is really a property on the project, and another lonely page for inter-project
dependencies, which is build information! 

There are two solutions. OK, that's arrogant; I'm sure there are plenty
of solutions. There are two solutions I have thought of. We could put all
non-build properties on one page that shows up if a project has a cnature,
and require plugin build systems to supply a page for setting build information
relevant to their builders. The upside to this approach is that if you
really want to have a requires-nature relationship, then you can. The downside
is that it requires more redesign of the standard build system and we don't
have much time allocated to do that (read none). 

Another solution is for suppliers of a builder to remove the requires-nature
dependency. It isn't as though the cnature supplies a ton of information
as it stands, and in terms of storing, all it really does is delegate the
persisting of information to the IStandardBuildInfo which uses the persistent
properties mechanism. You could easily do the same through your nature-supplied
property page and have more control over the look and feel.

That's my $.02 


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

"Alex Chapiro" <achapiro@xxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx

07/07/2003 02:58 PM

Please respond to
cdt-dev@xxxxxxxxxxx

To	<cdt-dev@xxxxxxxxxxx>
cc
Subject	[cdt-dev] About project properties.

I downloaded the latest code from CDT head branch. I have a question about
implementation of Paths and Symbols property page. Is there a way to hide
this dialog? It seems to be very inconvenient for those who provide their
own builders because it can duplicate their implementation. This is what
happens with QNX builder now: user has a bad "feature": to control
include
paths from two different places in a different ways and store them in
different places.

Alex Chapiro.

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev