Re: [cdt-dev] CDT extensions Proposal

["Alain Magloire" <alain@xxxxxxx>]

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

8-)
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.