RE: [cdt-dev] CDT extensions Proposal

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

Alain,
Thanks for the reply. I now understand the intent of the feature a bit
better. Just to summarize, you want to manage extension points; there will
be an API to get the values, and a way to specify and reset values to their
defaults. The .cdtproject file will be the repository for this information
on a per-project basis. The default values will be stored in the project
owner for easy retrieval.

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

OK, let me get this perfectly clear. Again, speaking strictly about the
builder and recognizing that your mechanism has a wider application, we will
still use the project nature to associate the builder with the project,
right? The information about that association will be stored in the
.cdtproject file. In this case, we do not necessarily have to allow the user
to change the information, but we can use your mechanism to retrieve the
extension point information if we need to. Is that a fair summary of this
one, narrow use case?

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

OK, I think I understand what you are saying here. Again, keeping my focus
on the build, the .cdtproject file will be the repository for which builder
is currently associated with the project and maybe other extensions as well,
such as what toolchains are defined. Does your mechanism have a way to group
related extension points together or specify some as mutually exclusive so a
user cannot get to a point where we specify invalid combinations of
extensions?

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

I think this is a very useful aspect of the design. In fact, I can see
adapting it to the new build model/builder design quite easily. Again, just
to make sure I understand this, it would be the responsibility of the ISV to
define these defaults in an implementor of ICOwner that they supply as part
of their addin. So, you will create a QNX project ICOwner, and I will create
a Managed Build ICOwner, and Sam might want to create a Timesys ICOwner,
etc.

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

I'll give that a try. Thanks,

Sean Evoy
Senior Software Engineer
Rational Software