[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Toolchains in CDT
|
Jeremiah,
Thanks a lot for your feedback and your comments. Greatly appreciated.
Comments and questions inline below.
Pierre-Alexandre
On Wed, 2004-02-18 at 09:13, Lott, Jeremiah wrote:
> 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.
You talk about finding at runtime the toolchain, but I guess you need to
have already an idea of where to look for, don't you? Else how do you
find your toolchains?
Are you willing to support toolchain that you wouldn't package and ship
and wouldn't have eclipse abilities included? (like generic gnu
toolchain we can download anywhere?)
In your sample code, it looks the path comes from the xml file. Would it
be written at installation? Maybe we have similar way of doing thing...
in MontaVista we use one plugin for each toolchain (that we ship, though
it is quite generic). It doesn't mean that the user can't install it
anywhere. Actually to allow that we use the eclipse links mechanism
which allow you to install plugins wherever you want and then add this
additional feature/plugin location to eclipse. This link can easily be
created at install time, it is just one very simple file to copy in your
eclipse/links directory.
>
> > 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);
>
> }
This is basically how I see it also. I agree the not all tools work the
same, and not all tools work in command line. With GNU tools it is
likely to be the case, so maybe they could have common interface but
that something else. You interface declarations is basically how I was
thinking of it.
>
> 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.
I think ICToolchain may be of some use. It would create a common
interface for all part wanting to interact with C/C++ application. So
that they wouldn't have to be specific. On the other hand, I think the
IToolchain interface is too generic to address the need of C/C++
specificities.
Also, if (and only if) we have a tool extension points, and that the
tool specify to which toolchain it applies, it would be a way of
applying a tool to all C Toolchain. This way, I could have a debugger
which is used by all C Toolchain. I am not totally sure if it is useful
or not but I thought some people may find some use of that.
>
> 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.
I think we need to distinguished to level of customization. The ISV
level and the user level. I am not sure exactly what level of
customization should be left to the user at the end. The ISV on the
other hand may want to do its own recipe for the toolchain. He may want
to add a special tool (e.g: debugger, idl compiler) on top of your/our
toolchain and it would be nice if he could do that without having to
write any code just some xml. But it maybe an utopia from my part.
For the user, at the end, I guess we could still add a property page to
customize the toolchain depending on the tool it contains, so that the
user can choose between the n compiler or others... But at the same time
we may want to not allow the user to be able to change everything for
support or other reasons. This 'expert' configuration needs be optional
because else support for company like ours would be almost impossible.
In what you said, I really like the idea of Capability instead of Tools.
It may be more appropriate as some tools work in pair or more. Often we
will have 1 Tool for one Capability but as you said it would allow to
treat for complicated cases.
>
> > 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.
Yes and no. I would like my ISVs or my partners to not have to write any
code if they want to replace and add a tool unless they want to add
specific UI or if there tool is very different from the ones we provide.
I would like them to be able to have their tool integrated in my
toolchain without major effort from their side and my side.
Also if we want to attract tool implementors to eclipse, I think it
would be nice if their tool could work easily on any distributions
(Timesys, Montavista, QNX, Rockwell or others) without having to do
different implementation each time for the toolchain.
>
> 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. :(
I have to admit that I didn't have the time to look a lot at Java
implementation. But I guess the C/C++ world has a more complicated
toolchain model though at a high level there are similarities that could
be underlined in the abstract IToolchain layer.
>
> 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).
I completely agree that a UI should be for a class of toolchain and that
we should allow extension for people who wants to add other toolchains
or capabilities.
>
> 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.
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
