Re: [cdt-dev] Toolchains in CDT

[Sean Evoy <sevoy@xxxxxxxxxx>]

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.

> 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.

> 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.

> 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?


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?

> 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.


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