[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Toolchains in CDT [TS-0062-1]
|
Title: Message
I'll say up front, I'm not asking
this to be applied, but people wanted details on my suggested approach for toolchain support and this seemed
the easiest way.
OK, here's my rough proof-of-concept
for the toolchain support. It doesn't currently have any UI with it, I'm just editing the .cdtproject
file to add the toolchain. Also, right now only a single toolchain can be added at the project
level. However I think we should support
the possibility of multiple
toolchains for a project. In the case of managed build, I would think one per configuration might be
the right granularity. The "core" of
the toolchain stuff I put in a new plugin for now
(org.eclipse.cdt.toolchains). It's
contained in the attached zip file. However, it's not very many classes,
and probably should be integrated into org.eclipse.cdt.core plugin before I
submit it. For any new classes right now the copyright statements are also
wrong. I'll change it to a CPL copyright before submitting a real
patch.
The toolchain "core" is
designed to be very extensible. Each cdt subsystem that wants to interact
with a toolchain (managed build, debugging, binary parsing, etc.) can write its
own capability interface. For an example, I expect that the debugging
capability will look alot like the IDebugger
interface and binary parsing like the
IBinaryParser interface.
I also expect that that CDT
will have a default toolchain factory extension that allows a user to register a gnu-based cross toolchain
manually (using a UI of some sort). Toolchain factories for other
toolchain types (Intel?, Microsoft?)
could also be added to the core. Also vendors can add custom toolchain factories to automatically
discover their own toolchains. For example, our CDT product will most like include a toolchain factory
that discovers timesys toolchains
automatically.
For this prototype I created a
Managed Build Capability. Essentially this capability allows the toolchain
to insert its own tool implementations in for the ones the managed build
expects. I had to perform a minor refactoring to get this working which is
why the patch is so big. I renamed
org.eclipse.cdt.managedbuild.internal.ToolReference -> ConfigToolReference
and added a new abstract class
org.eclipse.cdt.managedbuild.core.ToolReference. The abstract class just
represents any class that wants to override tool behavior.
ConfigToolReference extends ToolReference and specifically overrides the
options. Before both these concepts were in the same class. I had to
do this because the Itool instance returned from the
ManagedBuildToolchainCapability needed to be a tool reference, but extending
directly from the existing ToolReference class was causing problems. You
should diff org.eclipse.cdt.managedbuild.internal.ToolReference
from cvs against my new ConfigToolReference if you want to see what exactly I changed in that
class.
I also created a simple
"test" toolchain factory, so that I could see it in action. It reads a
properties file and appends a prefix on the front of every toolchain. This
is just temporary until I make a "real" implementation. If you want to see it in action, add:
<data>
<item
id="org.eclipse.cdt.toolchain"
factoryId="org.eclipse.cdt.toolchain.tests.TestToolchainFactory"
toolchainId="test-toolchain"/>
</data>
To your .cdtproject file.
You'll have to restart Eclipse to get it to properly re-read the file. Hope this is what people are looking
for.
Jeremiah Lott
TimeSys Corporation
Sounds
like a great idea. I'd like to see more details on how it would work and what
impact it would have on current components and workflows. In particular, can
it handle multi-target projects, i.e. multiple toolchains for a given project.
Also, we want to make sure we don't get too gnu specific and maintain
flexibility to work in different types of environments.
Doug Schaefer, Senior Software Developer
IBM
Rational Software, Ottawa, Ontario, Canada
"Lott, Jeremiah"
<jeremiah.lott@xxxxxxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx
01/30/2004 12:52 PM
|
Please respond
to
cdt-dev@xxxxxxxxxxx |
|
|
To
| <cdt-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| [cdt-dev] Toolchains
in CDT |
|
Hey CDT folks. TimeSys is looking at moving our product line
over to
CDT 2.0. One of the things we have in our CDT-based product
that is not
in core CDT is the concept of "toolchain". We would like
to have this
concept added to CDT 2.0 (assuming the group agrees).
Right now we
essentially use toolchains in three places. Our
managed build allows
you to choose a toolchain to indicate what
cross-compiler to use. Our
debug panels allow you to choose a
toolchain indicating what gdb
executable to run. The binary parser
uses the toolchain to figure out
what executables to use for addr2line,
c++filt, objdump, etc. In each
of these cases the user can choose
toolchain from a drop-down list that
contains applicable toolchain
installed on the machine. The contents of
the list could be
statically defined by the user or dynamically
discovered. A
"ToolchainFactory" extension point would be added so that
vendors could add
plugins to do dynamic discovery for their own
platforms.
Do people
think this would make a good addition to CDT? The idea would
be to
make it more generic than just the three areas I mentioned above.
A
toolchain could indicate what operations it supports so that an area
of CDT
can easily search for toolchains appropriate to a particular
operation (and
let the user choose from that filtered list). I've
actually been
working on a proof-of-concept with the CDT managed build
system if people
are interested in seeing it. Thanks,
Jeremiah
Lott
TimeSys
Corporation
_______________________________________________
cdt-dev
mailing
list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
Attachment:
toolchain-proto.patch
Description: toolchain-proto.patch
Attachment:
toolchain-proto-plugins.zip
Description: toolchain-proto-plugins.zip
