RE: [cdt-dev] Toolchains in CDT

["Lott, Jeremiah" <jeremiah.lott@xxxxxxxxxxx>]

> Ok, here is an example, the binaryParser.

> The way it is done now, IBinaryParser is an extension point, It is set
on the 
> project via the PropertyPage, some parsers say the GNUElf parser needs
tools, and > they provide a UI to set the paths, for things like
addr2line, c++filt etc ..

> What will be the workflow now ?

OK, I see two options.  The first is to create a toolchain capability
that provides just the  paths to the tools you are looking for.
Something like this:

IParserToolCapability extends IToolchainCapability {

  String TYPE = "IParserToolCapability";

  boolean supportsParser(IBinaryParser parser);
  
  String getToolPath(String toolType);

}

The when the user chooses a parser from the drop down in the properties
page, they would also  need to choose a toolchain to accompany it.  The
UI would use the supportsParser method to  determine what toolchains to
show in the drop-down.  Once the user chooses the drop-down the
toolchain id for the chosen toolchain (and toolchain factory) are saved
in the project.  The  IBinaryParser extension would also be added to the
project, as it is now.

When the binary parser needs a tool (say addr2line) it would do
something like this:

IToolchain tc = toolchainManager.getToolchain(factoryId, toolchainId);
IParserToolCapability parserCap = 
	
(IParserToolCapability)tc.getCapability(IParserToolCapability.TYPE);
String addr2linePath = parserCap.getToolPath("ADDR2LINE");

Of course there would need to be a lot of null checks, etc. but this
would be the general  idea.

The other option is to have the toolchain capability return full
implementations of  IBinaryParser.  The flow for the user would then
probably be choose a toolchain, then choose  from the binary parsers the
toolchain supports.  The toolchain id, factory id, and parser id  would
be stored in the project.  The capability would be something like this:

IBinaryParserCapability extends IToolchainCapability {

  // TODO: this isn't a great name for this interface, 
  // I'll come up with something better
  interface IBinaryParserRecord {
     String getDisplayName();
     String getId();
  }

  String TYPE = "IBinaryParserCapability";

  IBinaryParserRecord[] getSupportedParsers();

  IBinaryParser getBinaryParser(String id);

}

When you needed the binary parser instance for a project the code would
be like this:

IToolchain tc = toolchainManager.getToolchain(factoryId, toolchainId);
IBinaryParserCapability parserCap = 
	
(IBinaryParserCapability)tc.getCapability(IBinaryParserCapability.TYPE);
IBinaryParser parser = parserCap.getBinaryParser(parserId);

We would provide base classes that the toolchain providers could extend
for the common types  of parsers, GNU, ELF, windows PE, etc.  Basically
the classes that are there now, except  maybe we would add some
protected "hook" methods that allow a subclass to override certain
types of behavior more easily.  In this way it is similar to the
approach Chris Songer  brought up, as it involves subclassing binary
parsers.

I think I prefer the second approach, as it lets toolchain vendors
override other behavior  besides just the location of command lines
tools.  They could implement the functionality in  java, for example.
Or their command-line tools could be very different from the standard
ones in terms of the options they support, etc.  The only thing I don't
like about it is that  it seems to replace the project extension point
stuff that is in there now, and I don't want  to re-invent the wheel.

What do you think of these ideas?

  Jeremiah Lott
  TimeSys Corporation