[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Toolchains in CDT
|
More comments. I snipped up the email as otherwise this will get too
long.
Jeremiah
-----Original Message-----
From: Pierre-Alexandre Masse [mailto:pmasse@xxxxxxxxxx]
Sent: Wednesday, February 18, 2004 2:39 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Toolchains in CDT
> 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?
We have a centralized "registry" of TimeSys toolchains that are
installed. Basically, a big file which lists them all.
> 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).
Absolutely. This may be where most of our disagreemet stems from. We
must be able to support a gnu toolchain that has no knowledge that it
will be used from Eclipse. We also must be able to support toolchains
that are downloaded from the web or built by the user. Having a separate
plugin for each toolchain that is installed would not be acceptable to
us.
> 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.
Perhaps we could support this way of doing things as well as a toolchain
factory. Actually what I would suggest for this is an implementation of
toolchain factory that reads extension points. I will give more detail
separately (at end of message). However, I don't think I could clear
contributing that myself, as that's not how TimeSys plans to support
toolchains. If other people in CDT are interested, you and they could
work together to contribute this. If not it could be a proprietary
implementation of toolchain factory that is part of your product, which
you could potentially contribute at a later date.
> 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.
OK. At least we've managed to agree on one point. :)
> 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.
I think my main concern about an ICToolchain interface is that I don't
think that being a particular "type" of toolchain is flexible enough at
the framework level. For one, being a JavaToolchain and a CToolchain
aren't necessarily mutually exclusive. We could use multiple interface
inheritance to solve this, but it introduce the possibility that
JavaToolchain and CToolchain contain conflicting methods. That means
the the JDT team and the CDT team would have to coordinate on the
definition of these interface. This seems infeasible. By making the
customized interfaces at the capability (or tool) level the possibility
of conflicting interfaces is removed.
> 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.
OK. I think I understand. It seems to me, what would be most useful
for you is a way to define a toolchain which is basically another
toolchain with one or more command line tools replaced. I think this
should go into the extension point based toolchain factory, more detail
at end.
> 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.
My solution to this is to allow the user to change which tool(chain)s
are being used only at certain well defined points. For example, a user
can choose what tool(chain) to use as a compiler (managed build), which
to use as the debugger, and which to use as a binary parser. To me this
also defines the logical breakdown of where "capability" interfaces
should be defined.
> 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.
OK. Good.
> 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.
As we are planning to use very different mechanisms for toolchain
discovery, allowing the ISVs to replace any tool from any toolchain from
any vendor is logistically impossible (or at least very difficult). I
see a few levels of integration.
1. ISV is planning to provide a tool/toolchain that is so different from
any supported in base CDT that they need to write custom java code to
handle it. In this case they may as well write a toolchain factory.
2. ISV is planning to provide a toolchain that is basically the same as
one supported in CDT (e.g. a custom gdb distribution). They want to
discover toolchains in a way not related to Eclipse plugins. (e.g. the
TimeSys centralized file way). They will need to write a custom
toolchain factory to parse their format.
3. Same as (2) except they will be installing an Eclipse plugin when the
tool is installed. (i.e. The way you described in your mail with a 1-1
correspondance between toolchain installs and plugins). In this case,
they would want to use the extension point based factory you provide.
This is a good argument for contributing this to CDT, instead of making
it proprietary.
> 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.
This UI would pretty much only be useful for a user to import a
toolchain installed on their system. For example, a GNU-specific one
might ask the user to specify the location of gcc, ld, addr2line, etc.
I would see it working like so:
-UI stores information collected from user in the Preference store.
-There is a toolchain factory which reads the preference store and
returns a list of IToolchain objects
As I said before my plan wasn't to contribute anything in this area at
this time, and instead allow individual vendors to implement this
themselves. We can work on getting a standard user-defined toolchain UI
in after CDT 2.0, if desired.
I also realized this feature might not be desirable for all vendors.
For example, you said you don't want to support users downloading
arbitrary toolchains from the web, so you might not want user-defined
gnu toolchains in your product.
-----------
OK. Here's my general suggestion if you want extension point based
definition of toolchains. If you look at my xml-based toolchain factory
example:
> 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;
> }
>
> }
There's nothing to stop this from being altered slightly to query an
extension point instead. An extension point is basically xml elements
with a different API. I won't bother repeating a full altered version
as I think it is fairly obvious what it would look like.
The factory would have to be toolchain type specific, but the extension
point not necessarily. For example the extension point could be
something like this:
<extension id="myToolchains"
point="org.eclipse.cdt.toolchains.Toolchain">
<toolchain id="MVista-i586-linux" name="i586-linux"
vendor="MontaVista"
factory="org.eclipse.cdt.toolchain.gnu.ext.ExtGnuToolchainFactory">
<tool type="CC" location="/opt/mvista/bin/i586-linux-gcc"/>
<tool type="CXX" location="/opt/mvista/bin/i586-linux-g++"/>
<tool type="LD" location="/opt/mvista/bin/i586-linux-ld"/>
<!-- etc... -->
<path type="LIB" location="/opt/mvista/lib"/>
<path type="INCLUDE" location="/opt/mvista/include"/>
</toolchain>
<toolchain>
<!-- etc... -->
</toolchain>
<extension/>
For the most part I see ISV's providing complete capabilities, and
therefore separate toolchains. However, if you wanted to allow
overriding a single tool you could allow syntax like this:
<toolchain id="ISV-overrideToolchain" name="i586-linux-ISV" vendor="ISV"
base="MVista-i586-linux">
<!-- override just the compiler -->
<tool type="CC" location="/opt/isv/bin/gcc"/>
</toolchain>
If you wanted to allow overriding all toolchains that match a certain
pattern, then you could add that. One easy way might be
base="MVista-*", although that seems potentially dangerous.
Just some ideas. Mostly I wanted to point out that ToolchainFactory can
support both our situations.
