Skip to main content

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

> 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.
Please, I think this has been a point of contention: we are *not* proposing
that we replace the current model.  We would like to have the factory toolchain
extension point available *in addition to* the existing model based on extension
Right now, we (TimeSys) have over 100 distinct toolchains - all are binutils/gcc
based cross-compilers targeting Linux, so any given toolchain is generally
identical to any other in terms of what tools it supplies, how they are used,
etc.  The current extension point model used to declare build targets for
managed builds is extremely cumbersome in this situation.
Quite aside from this, while there may be a higher-level abstraction than
"toolchain", I'm not sure that pursuing it is especially useful.  As Jeremiah
pointed out, when we refer to "toolchain", we're really talking about the
tools, libraries, headers, etc. that are needed to produce a final executable.
Even JDT follows this general concept - you select the JDK you are compiling
against; you don't specify each individual tool you want to use, on a per-
project basis.  Our experience is that in the vast majority of cases, you don't
*want* to mix-n-match tools - you want to use a specific instance of a compiler
with it's associated linker, assembler, headers, libraries, etc.
Mix-in tools (IDL compilers, etc.) are a different case - these are tools that are
essentially indepent of any particular toolchain.  I can imagine providing an
extension point that allows a mix-in tool to say "consider me a part of any
applicable toolchain", ex:
<tool-mixin id=''>
  ... various other bits of tool data
Here, you'd be declaring a mix-in tool that should appear to be part of any
toolchain.  Filters might be applied so that you could limit contributions
by arch type (ex, only x86 toolchains, etc.), by OS (ex, Windows, Linux, etc.)
or some other criteria.
Discussion and debate about the ideal toolchain model is certainly good.
On a practical level, though, there is also an immediate need and desire on
our part to see *some* kind of toolchain support introduced in CDT 2.0.
We'ew willing to do the required work and provide an initial implementation,
which may not meet all the requirements of an ideal toolchain model, but will
at least give us a more concrete starting point for debate on future development.


Back to the top