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