| Re: [cdt-dev] Programmatic creating of custom toolchains |
|
Hi Andrew, Meanwhile I found some available public API which I could use to configure most of the parts like this (or similar): Create a configuration: IConfiguration config = managedProject.createConfigurationClone(ManagedBuildManager.getPreferenceConfiguration(false), ManagedBuildManager.calculateChildId(USER_CONFIGURATION_ID,
buildSpec)); ... Create a toolchain for the configuration: IToolChain toolChain = config.createToolChain(null, "com.windriver.cdt.core.WRGnuToolChain", "WR Gnu Tool Chain", false); ... Create a tool for the toolchain: ITool tool = toolChain.createTool(tools[i], "com.windriver.cdt.core.WRGnuCTool", "WR Gnu C Tool", false); ... Create an input type for the tool: IInputType inputType = tool.createInputType(null, "com.windriver.cdt.WRGnuCInputType", "WR Gnu C Input Type", false); inputType.setLanguageIdAttribute("com.windriver.cdt.core.wrGnuC"); inputType.setSourceContentTypeIds(new String[] {"org.eclipse.cdt.core.cSource"}); ... Since all this is available as public API I assume that creating all these elements programmatically is valid? Still, there is only the API for the settings before language settings providers were established – so if creating such constructs programmatically is supported,
the configuration of language settings providers programmatically should be supported too. The reason why I would like to create the toolchains outside of plugin.xml: I would like to configure the toolchain at project creation time since the toolchain should only be available when using my own project creation wizard for
a specific project type (a user-defined project type configured as part of the buildDefinitions extension).
When the toolchain is configured within plugin.xml, it is also visible within the “New C/C++ project” wizard, where it makes no sense since the environment
which is provided via projectEnvironmentSupplier only for the specific project type is not known for that C/C++ project type and therefor the toolchain will not work correctly since it depends on the provided environment variables. Currently I am still struggling with getting all this to work programmatically (even the code shown above is still not working as I expected it to work) – hopefully,
this is an obtainable project after all! Any input or comments on this topic would be great and highly appreciated! Thanks in advance! Best regards, Caroline From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Andrew Gvozdev Hi Caroline, I am pretty skeptical about that. It looks to me that current MBS toolchain is not intended to be created programmatically from outside. The design was for it to be "easily" created from plugin.xml markup. ToolChain class is internal and
IToolChain interface is marked with @noextend @noimplement. AFAICS, there are some other indications in the code. If I were to implement or modify it from outside plugin I'd brace for a few of difficult issues to solve. What is the reason to switch providers (/options) programmatically on toolchain level? Perhaps the logic could be implemented inside the provider? Thanks, Andrew On Fri, Nov 23, 2012 at 6:36 AM, Rieder, Caroline <caroline.rieder@xxxxxxxxxxxxx> wrote: Hi all, I am trying to programmatically create a toolchain with corresponding tools. I saw that multiple parts of such a toolchain are only available via internal API.
What I am missing: How can I programmatically define the language settings providers for a toolchain? ToolChain provides getDefaultLanguageSettingsProviderIds() but there is no API to set such providers for a created toolchain.
So how could I implement this to get the same results as when defined within plugin.xml like this?
<toolChain
archList="all"
id="com.windriver.cdt.core.WRGnuToolChain"
languageSettingsProviders="com.windriver.cdt.core.project.WRGnuBuiltinSpecsDetector"
name="WR Gnu Tool Chain"
supportsManagedBuild="false">
… How can I add a tool option to get the same as when defining within plugin.xml like this? I could only find
<option
browseType="directory"
id="com.windriver.cdt.core.gnu.c.settings.holder.incpaths"
name="Include Paths"
command="-I"
valueType="includePath">
</option> Could somebody please give me a hint on how to accomplish this (if possible by using as little internal CDT code as possible)? Thanks in advance!! Best regards, Caroline Caroline Rieder | Wind River | Senior Engineer
|