Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Toolchains in CDT

This is a very interesting proposal that has wide-ranging implications. I have put some comments/questions in-line below.

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


Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada

Back to the top