[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Creating tool options programatically
|
I used EMF for only a year, but I do agree that it's a wonderful technology. Having said that, I don't think any of EMF features listed below are needed for MBS. On the downside, an EMF learning curve would create an additional barrier for people who are not familiar with EMF. EMF persistence is particularly hard to get right. I wouldn't use it for storing project build configurations.
-sergey
On Mon, Apr 27, 2009 at 12:05 PM, Christian W. Damus
<cdamus@xxxxxxx> wrote:
Hi, Sergey,
Yes, some component (probably MBS) would nonetheless need to provide code that injects the toolchain definitions loaded from the EMF representation into MBS, using its API. Although, if MBS' tool-chain metamodel *is* the EMF-generated interfaces, then there wouldn't be any conversion to do. Except to support the current mode of defining all of the tools in the plugin.xml, of course.
My 6 years of experience in the Eclipse Modeling Project naturally bias me towards an EMF-based solution. Whenever I see metadata as complex as MBS's tool-chain definitions, my knee jerks and I use EMF to define a model that allows me to visualize and control the information. :-)
However, there are real advantages to using EMF in a situation like this:
- the Ecore metamodel and run-time system provide a number of useful capabilities for data modeling, including but not limited to:
- strong references between objects (no need to reference objects by ID)
- notifications when objects change
- a rich reflection API
- EMF provides a user-friendly editing experience that is much richer than the PDE's extension editor:
- default generation of tree editors and form-based editors
- integrated validation
- semantics-aware compare/merge for team environments, with EMFT Compare
- with GMF, graphical editors
- with TMF, DSL editors
- defining toolchains in EMF resources removes a lot of overhead from the Eclipse extension registry. Moreover, as EMF can access resources anywhere in the universe (even remotely via http), toolchain definitions don't have to be delivered by plug-ins at all. Imagine that CDT could provide a central repository of toolchains at Eclipse.org and publishing new definitions at any time for clients to discover
- EMF is the basis of model-to-model transformation technologies that could simplify the problem of migrating toolchain definitions as the MBS schema evolves
- not only can toolchain definitions be modeled using EMF, but also *instances* of toolchains in C projects (option settings etc). All of the same benefits apply
Then there's all of the generation/transformation/etc. possibilities that would be opened up by combining EMF-based tooling metadata with an EMF-based C/C++ language model. But, that's another subject ...
This is just $0.02 from somebody with, as yet, only a slim understanding of the problems faced by C developers and by CDT developers ... :-)
Cheers,
Christian
On Mon, 2009-04-27 at 11:06 -0700, Sergey Prigogin wrote:
On Mon, Apr 27, 2009 at 10:55 AM, Christian W. Damus <cdamus@xxxxxxx> wrote:
Hi, Doug,
Why build a tool chain with Java code? It should be described as an instance of an EMF model.
Christian, could you please elaborate on the reasons to use EMF.
At run time an EMF model is just a set of Java classes, so support for tool chain EMF models implies an ability to build a tool chain in pure Java.
cW
-sergey
On Mon, 2009-04-27 at 13:44 -0400, Doug Schaefer wrote:
This is definitely one area I want to enhance with a new rev of the build model. There are limits to what you can do with the dynamicElementProvider, for whatever reason. I'd like to be able to express my entire tool chain using Java. That needs to be made easier.
Doug.
On Mon, Apr 27, 2009 at 1:09 PM, Chris Recoskie <recoskie@xxxxxxxxxx> wrote:
The buildDefinitions extension point has a provision for this... the dynamicElementProvider. However, I don't think anyone has used this in quite some time and so I'm not sure it's fully functional any more.
This is from the extention point description:
<!ELEMENT dynamicElementProvider EMPTY>
<!ATTLIST dynamicElementProvider
class CDATA #REQUIRED
name CDATA #REQUIRED>
An optional element that allows a tool implementor to supply a class that creates one or more dynamic toolchain elements. For example, the class might create a new tool reference based on the contents of a special file, and a new target that uses that reference.
- class - The class that implements the IManagedConfigElementProvider interface. The logic of determining the elements is left to the implementer, but they must be correctly formed or the build model will have trouble loading.
- name - A meaningful name for the type of element being provided.
===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto
![Inactive hide details for Mike Wrighton <mike.wrighton@xxxxxxxxxxxxxx>]()
Mike Wrighton <mike.wrighton@xxxxxxxxxxxxxx>
Hi,
Does anyone know if there's a way to create (or populate) tool options
at runtime? I need to query the toolchain for a list of supported
targets and display them in a combo.
Cheers,
Mike
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
