RE: [cdt-dev] CDT extensions Proposal

["Evoy, Sean" <sevoy@xxxxxxxxxxxx>]

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: 

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

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.

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.

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?

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.

Sean Evoy
Senior Software Engineer
Rational Software