[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Toolchains in CDT
|
Title: Message
Comments are inline.
Jeremiah
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
