[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Toolchains in CDT
|
Hi,
This is about your proposal on the Toolchain Factory extension point.
Sure it would be simpler to have a unique extension point to integrate
multiple toolchains if you deliver complete toolchains. But I don't
think this model would appropriate for people contributing in just one
tool or two.
I started to think about what a toolchain model could look like.
Here is how I see it.
1. the very abstract level (the layer which should be in the Eclipse
Platform):
IToolchain is a set of tools. The Toolchain has an id and a name. Each
tool has a unique id. There should be an isAvailable method implemented
for each tool (in case it depends on external tool and to be sure they
are present on the system)
2. the C abstraction level:
ICToolchain extends IToolchain and has at least the following: a
compiler, an application linker, a library linker, a debugger (and maybe
a couple of others)
One idea also could be to have an architecture (x86, arm_xscale_le, ...)
associated with the toolchain (though I am not sure how exactly we could
define an architecture).
3. Then we can have as many level of abstraction of needed. I guess we
should have a ICGnuToolchain extending the ICToolchain and then we
should have a default implementation.
Extension Points:
I think it should work sort of the same way than Editors and actions.
We should a Toolchain extension point and a Tool extension point. The
Tool extensions would define to which Toolchain they apply. For example
myDebugger could be associated with all ICToolchain or maybe only to all
ICGnuToolchain or finally only to MyToolChain.
I guess that people contributing one or couple of tools would really
prefer such a model instead of having to contribute and hack a complete
toolchain.
There would also be ToolchainManager to manager the tool extension
points and register the tools to the appropriate toolchains.
The problem with a unique Factory toolchain extension points is that it
is too big. The granularity doesn't allow to participate in just a tool.
And if we want the model to be also accepted by the Eclipse Platform as
they are working on creating a toolchain framework (of what I
understood), we need to offer a good granularity and flexibility.
Also a unique factory toolchain extension point, in my mind, is not
really in the line of the extension point/extension eclipse model as it
doesn't allow easy and simple contribution. I think it is more in the
Eclipse philosophy to break it down so that people can participate only
in one small part of it, the same way you want to contribute only one
action but not the complete menu.
On another points, I have to admit that I didn't think of having
multiple tools available for one part (compilation, linker,...) and I
like the idea. I guess it would fit pretty easily in the model. I just
would like to add one more thing to it (which is very obvious and you
may have implied), there should be a default tool for the basic C Tool
(compiler, linker, debugger, ...).
I realize it is a pretty tough shift from the model that Jeremiah
provided earlier, I don't want to offend anyone, I just thought that
this comments could be contructive and help to build an even better CDT.
I hope this helps.
Pierre-Alexandre
On Mon, 2004-02-16 at 11:18, Lott, Jeremiah wrote:
> Comments are inline.
>
> Jeremiah
> -----Original Message-----
> From: Sean Evoy [mailto:sevoy@xxxxxxxxxx]
> Sent: Monday, February 16, 2004 12:30 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: Re: [cdt-dev] Toolchains in CDT
>
>
> Jeremiah,
> This is a very interesting proposal that has wide-ranging
> implications. I have put some comments/questions in-line
> below.
>
> [Snip]
> > 1. A user should easily be able to specify they want to use
> one of
> > our toolchains in a C-project.
>
> Based on your proposal, many of the core CDT features will be
> treated as toolchains with varying capability interfaces
> depending on the functionality of the specific feature. I can
> see the logic of toolchains as part of the core if it will
> help us support the diverse development environments of the
> end-user. Where I am a bit worried is how much of that we want
> to expose the end user to. My own feeling is that users are
> still thinking in terms of projects and build goals. They are
> probably more interested in creating a
> <insert-your-marketing-departments-idea-of-a-cool-name-here>
> project, adding a couple of files to it, and building. I
> guess what I am saying is that toolchains seem like an
> internal thing and we will need to present bundles of
> toolchains to users through another, higher-level concept.
> I'm not sure I agree. While the user thinks in terms of projects and
> build goals, they also think in terms of the tools needed to complete
> those goals. For example, in managed make a user may choose "linux
> executable" as the "platform", but they will also want to choose what
> version of gcc, ld, etc. they use. I think the user will see this as
> two logical steps, first choose the type of output (i.e. linux
> executable), then choose the toolchain to use (i.e. sh-linux
> toolchain). In particular I think this will be necessary when
> cross-compilation is the goal.
> > 2. Each time they need to specify a toolchain (managed make,
> binary
> > parsing, debugging) it should use the same name, etc. so as
> not to
> > be confusing.
>
> From the perspective of the CDT core they should all have the
> same type, but can/should we force vendors to supply all
> functionality in a limited range of types? I guess my concern
> is for the vendor whose tools cannot be easily partitioned.
> What if a new debugger toolchain was developed that provided
> its own strip capability, but still relied on some of the
> other functionality of the default binary parser such as
> addr2line (or at least did not provide those functions to the
> core)? Obviously, the vendor supplies an implementation of a
> debugger toolchain, but they now have an overlapping
> capability with the default binary parser. We will have to
> come up with some way to deal with these overlaps so the
> internal client knows which one to use.
> I think that this problem would exist regardless of how toolchains are
> provided. In what I propose the design of the capability would be the
> key. In the case above, I might suggest a toolchain which provides
> both a debug capability and a binary parser capability. The binary
> parser capability should extend some base class
> (e.g. GnuBinaryParserCapability) and override the strip method, but
> leave the default addr2line and c++filt methods. The other
> possibility would be to make the capabilities more granular, for
> example core might define a IBinaryParserCapability interface which
> corresponds to addr2line, c++filt and a separate IStripCapability
> interface. But I think this second possbility only makes sense if we
> think a separate implementation of strip is common.
> > 3. CDT should be able to "discover" toolchains installed on
> the
> > system at runtime. Either by reading descriptors or by
> having the
> > user specify information through a UI (or a combination)
>
> I agree completely. Imagine a user gets a new debugger that is
> binary compatible with their build tools. They probably just
> want that compiler to appear as an option in the list of
> debuggers when they debug their project. I doubt that they
> will intuitively say "Oh yeah, that's a toolchain, I'd better
> go change that somewhere". The more we hide the idea of a
> toolchain from the user the better.
> I'm not sure I understand the difference between the two scenarios
> that you present here. I saw two possibilities:
>
> 1. This is the one I prefer. When the user creating/editing a launch
> configuration the list of debuggers is built from the list of
> toolchains installed on the machine. Any toolchain which supplies a
> debugger capability would be listed.
>
> 2. The list of debuggers would be the same as now. First the user
> would choose the type of debugger (i.e. GDB-MI compatable debugger).
> Then the user would be presented with a list of toolchains that
> provide a gdb-mi compatable debugger.
> > 4. A toolchain vendor should not be required to have one
> extension
> > for each toolchain they provide. The number of toolchains
> is
> > variable (and are constantly being released).
>
> This leads me a to a practical concern. If we let users
> mix-and-match toolchains for a project, how will the CDT core
> be able to resolve toolchains that should not work together?
> One can easily imagine that a matrix of toolchain
> compatibility would be difficult to maintain. What if the
> builder was producing binary code that was incompatible with
> the changed binary parser or worse, caused it to die
> unexpectedly?
> I don't believe that this problem would be any greater than now. For
> standard make we allow users to mix and match as much as we want, so
> this is basically the same. For managed build, we set the binary
> parser automatically, and should be able to continue to do so with
> something similar to the following algorithm:
>
> IToolchain tc = configuration.getToolchain();
> IBinaryParserCapability cap =
> (IBinaryParserCapability)tc.getCapability(IBinaryParserCapability.TYPE);
> IBinaryParser parser = cap.getBinaryParser();
> project.setBinaryParser(parser);
>
> Obviously this is a simplified example. If the toolchain didn't
> provide a binary parser capability, then either the user would have to
> choose one, or we would choose the default one. For example, the
> default binary parser for linux executable would be the
> GnuElfBinaryParser, using the default tool locations.
> If functionality like the managed (or replacement) builder and
> binary parser are supplied as toolchains, then the core may
> not function if at least one is not present or working
> correctly. Maybe it is better say that we will have to be very
> strict about what the capability interface must supply?
> I saw two possibilities:
>
> 1. CDT will function without toolchains. Basically "no toolchain"
> could be an option, which would default to the behavior that is in CDT
> now.
> 2. CDT will autodetect toolchains that are installed on the path.
> Minimally, a toolchain factory that spits out a toolchain which
> corresponds to "gcc on path" would be provided with CDT. This would
> ensure that at least one toolchain is always present.
> > 5. While we have all gnu-based toolchain, having toolchains
> be just
> > a series of paths is naïve. Often there are quirks in
> particular
> > toolchains that need to be dealt with in the code. Ideally,
> these
> > should be dealt with by toolchain vendors, not by the CDT
> core.
> > (Although the core may need to become more flexible to
> support
> > variance in toolchains.) The problem is only compounded
> when you
> > look at supporting non-gnu toolchains as well.
>
> We should not do anything that would make it difficult to
> introduce non-Gnu (or any other) toolchains in the future. An
> IPath-based approach may not work for every case, but it is
> robust and simple and all of the required "stuff" is present
> in the core today. We risk losing some control over quality if
> the CDT core has to rely on toolchain vendors to work
> correctly or if everybody adds a new UI element to handle said
> "quirks". I guess I would feel a bit more comfortable knowing
> that there was a default implementation that worked with a
> minimum amount of coding. For example, if you create a new
> capabilities interface implementation, the default will just
> use IPath and invoke the command. If that is not enough, then
> you can customize.
> I think CDT should provide a set of base classes for a "GNU-toolchain"
> (and also other toolchains, if we can idenitfy the need for them). It
> could be used in one of two ways:
>
> 1. Call its constructor and pass it a bunch of IPath's (or maybe just
> Strings) for the tools. This would cover most people.
> 2. Sub-class the toolchain class and/or the various toolchain classes
> and override methods to "tweak" it to work with your toolchain.
>
> I don't think there is anything in the general toolchain design that
> is specific to gnu-toolchains. We would need to be careful in the
> design of each specific capability to ensure nothing gnu-specific goes
> in.
> To summarize, I like the proposal for discovering the
> capability of a toolchain and for putting the capabilities in
> an interface. Obviously, a lot of work will be needed to
> define what the minimum capability interface is for a
> toolchain. I can see how a toolchain vendor may want to bundle
> a set together for a project type (or some other
> organizational construct) but I am concerned about
> partitioning functionality and allowing users to mix-and-match
> potentially conflicting toolchains. I want to get a better
> handle on whether or not it makes sense to provide a builder
> as a toolchain, since the parser relies heavily on the build
> system (standard, managed, or whatever) to function
> correctly.
>
> [SNIP]
>
> Sean Evoy
> Rational Software - IBM Software Group
> Ottawa, Ontario, Canada
>
>
