[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] CDT extensions Proposal

> Hi Alain and David,
> I'm a bit uncertain of what the intent of the proposal is, at least in terms
> of the build model/build system. The documentation does not explain what
> deficiency the proposal is meant to address, nor whether it is being
> proposed as the "prefered way" to associate some, all, or just unique
> extensions with CDT projects.
> More to the point, Doug asked the question that first question that I had
> when I saw the example of the QNX builder in your document: 

The CDT extension proposal was not only targetting the builder, although
the example in the XML file was one presenting the builder.

> > I just made a quick pass through your proposal.  The first 
> > thing that came to mind was that it looks like some of what your 
> > are proposing here can be accomplished using Natures.  Certainly 
> > associating builders is usually done this way.  You could probably 
> > associate different tools with a project this way as well.  
> > Were there problems with Natures that you ran into?
> > 
> David replied:
> > Not quite the same as the nature since the extension behavior 
> > is not defined by its existent within the file but completely up 
> > to to one that put it there. The nature interface has a defined 
> > behavior wrt the project. The entries in the .cdtproject do not, 
> > its simply an extension point to project association.
> > 
> > The main idea behind this proposal is that as we define more 
> > extensions that fit a per-project use, then we have a mechanism 
> > that makes this very easy to do.
> > 
> I am confused by this response. Natures associate tools with projects. That
> association exists on a per-project basis. Your extension points operate at
> the same level of granularity. I really don't see that you can make the case
> that we need a new mechanism on the basis of what they apply to. I do see
> that natures are a bit of a straightjacket since they get configured once,
> and the only way to "reconfigure" them is remove and add a new nature.
> That's a chore for some types of extensions. However, here are my concerns
> from the perspective of the build.

The ".cdtproject" is not like the nature, it is a proposal to manage the
extension points on per project basis.  For example, the parser and help 
completion contributor are extensions points implementing particular modules
in the CDT.
# cat .cdtproject
    <extension id="org.eclipse.cdt.core.ELF" point="org.eclipse.cdt.core.BinaryParser"/>
    <extension id="com.qnx.tools.ide.doc.user.helCompletion" point="org.eclipse.cdt.ui.CCompletionContributor"/>

> 1. A builder needs information. The more work it has to do, the more
> information it needs. Clearly, converting between builders could be quite
> difficult depending on the "impedence mismatch". Storing the builder in the
> nature limits the number of ways a user can swap builders, so we (and other
> ISVs) have fewer use cases to support.

The current proposal of the builder contains many extension points that can
be managed by the cdt-extension mechanims.  We just want to provide a way
to __ manage extension points ___.

> 2. If we have just introduced another way to associate a builder with a
> project, what does it mean if the user sets one builder in the nature and
> one as an extension? Which builder wins? Does removing the extension mean
> reverting back to the default? See point 1 for a small sense of the dread I
> am experiencing just thinking about this.

Maybe the proposal was not clear enough, the cdt-extension manages extension
points not builders.

> 3. The way that natures work in team development is that the nature is
> configured once for a project, even if it is shared. I can see some users
> finding this a comfort and others a curse, but at least it makes sense; one
> person creates the project and configures its nature, and everyone else gets
> that project out of the repository, nature intact. How does your extension
> proposal work in a shared team setting?

You are probably referring to the ICOwner class, the behaviour may look
similar to a the nature counterpart but its goal is to provide a way to reset
the default extensions for a project and also tie a platform to the project
which is currently use by the debug/launch.  For example a QNX project is :

Elf parser
QNX specific help contribution
platform qnx

if the user mucks with the settings(changing the binary parser) then we can
restore defaults. 

> This is my first thinking on your proposal. Maybe with a better
> understanding of what you want to do with this will make me feel better
> about how it will live and play with the build system.

yes,  this is why we want to make proposals and make changes to the code
by iteration when having consencus/understanding.

To illustrate more, get the latest cvs, create a C project, bring in the
C editor the created ".cdtproject" and in the Property page change
the Binary parser extensiong from Elf <--> PE and see the ".cdtproject" file
adjust itself.

We have more scenarios coming later this week.