Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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
Sent: Monday, July 07, 2003 3:47 PM
Subject: Re: [cdt-dev] About project properties.

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] 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

Back to the top