[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Toolchains in CDT
|
I don't mean to rehash, but there are a couple things I'm not sure I
understand about your proposal. (The snippets are out of order)
> -----Original Message-----
> From: Pierre-Alexandre Masse [mailto:pmasse@xxxxxxxxxx]
> Sent: Tuesday, February 17, 2004 1:09 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: RE: [cdt-dev] Toolchains in CDT
> 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.
CDT/Eclipse should be able to detect any "tools" that are installed on
the machine at runtime. Say a user receives a new toolchain, how would
they make CDT recognize that toolchain? Remember that this toolchain
didn't necessarily know anything about Eclipse when it was installed.
So the solution needs to address both a user-defined toolchain and
automatic discovery of toolchains.
In particular, the full-path to the tool (say
/opt/timesys/toolchain/i586-linux/bin/i586-linux-gcc) can't possibly be
known when I'm writing the extension point. The user can change this
when they install the toolchain. My suggestion would yield something
like this: (I just made this up on the fly, so don't try to compile it
or anything :) )
class MyToolchainFactory implements IToolchainFactory {
public IToolchain[] getToolchains() {
Document doc = // read an xml doc somewhere on the
system e.g. /etc/timesys.xml
Element tcListElement = doc.getElement("toolchains");
NodeList tcNodeList =
tcListElement.getChildren("toolchain");
IToolchain[] ret = new IToolchain[tcNodeList.length()];
for (int I = 0; I < tcNodeList.length(); i++) {
Element tcEl = (Element)tcNodeList.getNode(i);
GnuToolchain tc = new
GnuToolchain(tcEl.getAttribute("id"));
tc.setDisplayName(tcEl.getAttribute("displayName"));
tc.setGCCPath(tcEl.getAttribute("gcc"));
tc.setGXXPath(tcEl.getAttribute("gxx"));
tc.setLDPath(tcEl.getAttribute("ld"));
// etc...
tc.setDefaultIncludePath(tcEl.getAttribute("includePath"));
tc.setLibraryPath(tcEl.getAttribute("libraryPath"));
ret[i] = tc;
}
return tc;
}
}
You would only need to create a specialized subclass of GnuToolchain if
your tools deviated from the GNU standard in some way. If you weren't
gnu-based then either you would either use another base class, or create
a completely new implementation of IToolchain.
> 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)
Is your proposal for the IToolchain/ITool interface to be something like
the following?
interface IToolchain {
ITool getTool(String id);
ITool getTools();
boolean isToolAvailable(String id);
}
interface ITool {
String getName();
String getID();
String getCommandPath();
}
The main problem I see with this is there is no logic in the
implementation about how to use the tool. As an example that someone
else brought up, think of "strip". Not all implementations of strip
accept the same arguments, input types, etc. I could see supporting
this:
interface IToolchain {
String getName();
ITool getTool(String id);
ITool getTools();
boolean isToolAvailable();
}
interface ITool {
String getId();
}
interface IStripTool extends ITool {
void stripFile(String inputPath, String outputPath);
}
I can't see a strong reason to introduce an ICToolchain subclass, CDT
should instead query the toolchain to see if it provides the tool(s)
that it is looking for. I moved getName() up to toolchain, as I think
uniform display name across tools is important.
The biggest problem I see with this ITool approach is it compounds the
"mix and match" problem. For instance if addr2line and c++filt are
separate ITool instances, then it might be possible for a user to choose
addr2line for one architecture and c++filt for a different one. I'm not
sure this is really what we want. That's why I had used a "capability"
which was a logical function from CDT's perspective and could be
implemented by one or more command line tools.
> 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.
To address your concern about contributing a single tool we could have a
ToolFactory as well as a ToolchainFactory (assuming we decided to take
an ITool approach). However, just creating an easy way to instantiate a
toolchain which contains just one tool would probably be easier.
Also, as you mentioned compatability with JDT/Eclipse, the "capability"
approach is much closer to what they have than an ITool approach.
Currently they have a IVMInstall and IVMRunner as equivalents to our
toolchain (at least in the context of debugging). The interface makes
very little mention of the specific location of particular tools (i.e.
java or javaw). These interfaces would be encorporated into the
toolchain capability approach by changing IVMInstall into
IJVMCapability, and removing the name and id method (as those will be
part of the IToolchain interface)
interface IJVMCapability extends IToolchainCapability {
IVMRunner getVMRunner(String mode);
File getInstallLocation();
LibraryLocation[] getLibraryLocations();
URL getJavadocLocation();
}
What they do have that I don't is the concept of IVMInstallType, which
also has a corresponding extension point. This is mostly used to drive
the "Installed JRE" property page. It also is used for limited
"auto-detection" of JVM installed on the machine. Unfortunately I'm not
sure this ports very well to the C/C++ world as implemented. :(
The equivalent of the "Installed JRE" pref page would be what we (at
TimeSys) call "user-defined toolchains". In fact we modeled our
user-defined toolchain support directly after this page. However having
a single user interface for all types of toolchains is infeasible.
Probably we would need a UI extension point e.g.
UserDefinedToolchainPage. It would be extended by, for example
GNUToolchainPage. I was going to postpone introducing something like
this until a later date (proabably after CDT 2.0) when the general
toolchain stuff was more mature. I was going to push off the
responsibilty of implementing this on particular CDT vendor (if they
want it).
The auto-detection from IVMType is very limited. Even the comment on
the method indicates its job is basically to auto-detect the VM that
Eclipse is running in. As I've already stated, we need something that
can detect a list of toolchains.
Somewhat separately I also wanted to address Sam's comment about mix in
tools:
> -----Original Message-----
> From: Robb, Sam
> Sent: Tuesday, February 17, 2004 2:15 PM
> To: cdt-dev@xxxxxxxxxxx; cdt-dev@xxxxxxxxxxx
> Subject: RE: [cdt-dev] Toolchains in CDT
> 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='some.tool.id'>
> ... various other bits of tool data
> </tool-mixin>
I can see having an extension for a particular type of tool. For
instance, an extension may specify what an idl compiler is, i.e. how and
when to invoke it. I believe the managed builder already has a tool
extension point intended for this purpose. But at runtime CDT/Eclipse
will still need to minimally detect where the tool is installed on the
machine (or the user will need to specify the location). There is also
still the possibility that multiple IDL compilers are installed on the
machine. A "one per workspace" system would be too much of a
limitation. To me this situation is text book example of when a
"factory" pattern should be used.
