[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Creating tool options programatically
|
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>
> >
> >
> > Mike Wrighton <mike.wrighton@xxxxxxxxxxxxxx>
> > Sent by: cdt-dev-bounces@xxxxxxxxxxx
> >
> > 04/27/2009 12:30 PM
> >
> > Please respond to
> >
> > "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> >
> > To
> >
> > "CDT General
> > developers
> > list."
> > <cdt-dev@xxxxxxxxxxx>
> >
> > cc
> >
> >
> >
> >
> > Subject
> >
> > [cdt-dev]
> > Creating tool
> > options
> > programatically
> >
> >
> >
> >
> > 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
>
>
> ______________________________________________________________
>
>
> Christian W. Damus
> Software Developer, IDE Team
> QNX Software Systems
>
>
> _______________________________________________
> 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
________________________________________________________________________
Christian W. Damus
Software Developer, IDE Team
QNX Software Systems
