[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] CDT extensions Proposal
|
Evoy, Sean wrote:
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.
Correct.
The default values will be stored in the project owner for easy retrieval.
The defaults will be stored in the file, which is really just what the owner
puts there when its 'configure' method is called, which is current only at
project creation.
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?
Well, in understanding how the builder can really use this facility I
think we need to step back and all understand what exactly this new build
model is going to support wrt building a CDT project. My current understanding
would be that this build model is an Eclipse builder which invokes various
tools at the various stages and where these tools are contributed via extensions,
if so then the .cdtproject would be the best place to hold this extension info.
But beyond that simple view, I was hopping that the build model support multiple
platforms within a single workspace, as well as a notion of referencing
(for lack of a better phrase) a "C/C++ binary project", which could simply be a set
of libraries and includes with some build configuration info. Now supporting
both of these scenarios we could easy extends the .cdtproject to contain build
configuration data, as well as maybe use the owner id or ICOwner interface to
contribute the platform specific build configuration (ie system include paths,
system library paths).
This just touches on some concepts which include the builder, one other area
of the CDT the could use information provide via the .cdtproject and owner would
be the parser wrt to system include paths.
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?
I thinks each component which uses the .cdtproject could enforce its own rules
wrt what you have mentioned, this could be via interfaces from that module or even
just through documentation which the ISV would use when contributing a part.
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.
You are correct with the idea that QNX and Timesys would be owners since they
both contribute platform information, but the Managed Build would be just a builder
that would be on the project, and would use build information through the owner
to build the project. Keep in mine also that both QNX and Timesys would
contribute to the Managed builder through extensions to support it on those
projects.
Now I know there are a lot of ideas I'm throwing around here with the builder but
we feel that builder is a very important part of the CDT. I think it may be a good
idea to either continue discussions in a phone call or better in person to hash out
further details here, What do you think?
Thanks
Dave.
