Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] adding a toolchain with common options to tools (Warren Paul)

It’s been quite a while since I looked at that code, but what I remember is there are actually two states of the option.  The getOptionById I believe gets you the working copy of the option.  So if you have the build settings UI open, that’s the current value in the UI, whereas getOptionBySuperTypeId gets you the persisted value.  When the UI is not open I think you just get the persisted option.  Basically when the id ends in .some_number it’s the possibly dirty working copy.

I also remember that changing these toolchain-wide options does not dirty the configuration by default.  Since you probably want to rebuild the configuration when changing such options, you need to handle that yourself.  It’s pretty easy though.  Just specify a valueHandler for each option.  Your valueHandler can extend ManagedOptionValueHandler and override handleValue.  Something like this:


public boolean handleValue(IBuildObject configuration,

IHoldsOptions holder, IOption option, String extraArgument, int event) {

if (event == IManagedOptionValueHandler.EVENT_APPLY && ((Option) option).isDirty()) {

IConfiguration config = ((IToolChain)holder).getParent();

if (config != null) {



return true;


return false;


From: Ashutosh <ashutoshpal2006@xxxxxxxxx>
Reply-To: "CDT list." <cdt-dev@xxxxxxxxxxx>
Date: Friday, September 18, 2015 at 1:53 AM
To: "CDT list." <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] adding a toolchain with common options to tools (Warren Paul)

Hi Warren,

Thanks for your response.
Earlier, I had played around a bit with Command-line generators (but at the option level). I had noticed that at least the 'All Options' scroll box in the Build Settings UI for tools was not getting updated when I changed the toolchain-level option value. The command generator was getting invoked but it was NOT picking the value entered in the UI, but was picking the value saved earlier probably in the .cproject file. The code for the command-generator for the option (added on the invisible option) is inlined below:

    public String generateCommand(IOption option, IVariableSubstitutor macroSubstitutor) {
         // get the selected project from workbench
        IProject p = getSelectedProject();
        if (p == null) return "";
        IManagedBuildInfo buildInfo = ManagedBuildManager.getBuildInfo(p);
        IConfiguration activeConfig = buildInfo.getDefaultConfiguration();
        IToolChain tc = activeConfig.getToolChain();
        for (IOption optn : tc.getOptions()) {
            if (option.getBaseId().equals("my.toolchain.compiler.model"))
                if (optn.getBaseId().equals("my.toolchain.general.model")) {
                    return "--model" + optn.getValue();
        return "";

My questions are:
1. Does the command-generator always picks the saved settings (from .cproject) and not from the UI? Would even the tool-level command generator (as you recommend) do the same? Or, is above code not correct to access tool-chain option value?

2. Does pressing 'Ok' on the C++ Build Settings dialog guarantee that the settings are saved on the file-system? I've sometimes noticed that the changes done in the build-settings UI are not getting reflected in the .cproject file?


Date: Thu, 17 Sep 2015 14:29:07 +0000
From: Warren Paul <Warren.Paul@xxxxxxxxxx>
To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] adding a toolchain with common options to tools
Message-ID: <D220377F.20870%Warren.Paul@xxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"

You can use command line generators for the tools in the toolchain that used the shared options.  You can then read the toolchain option value and not have to create these invisible copies in each tool.


protected String getFlags(ITool tool, String[] flags, String outputName) {

IToolChain toolchain = null;

IBuildObject parent = tool.getParent();

if (parent instanceof IToolChain){

toolchain = (IToolChain)parent;

} else if (parent instanceof ResourceConfiguration) {

toolchain = ((ResourceConfiguration)parent).getBaseToolChain();


// get the memory model from the common toolchain options

IOption model = toolchain.getOptionBySuperClassId("my.toolchain.general.model");

From: Ashutosh <ashutoshpal2006@xxxxxxxxx<mailto:ashutoshpal2006@xxxxxxxxx>>
Reply-To: "CDT list." <cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>>
Date: Thursday, September 17, 2015 at 2:55 AM
To: "CDT list." <cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>>
Subject: [cdt-dev] adding a toolchain with common options to tools

Hi All,

I am adding a toolchain to CDT using the buildDefinitions extension point of the Managed Builder. My toolchain has a few common options that need to be passed to all the downstream tools (i.e. compiler, linker, archiver etc), for example:

mycc   --model <MODEL_NAME>
mylink --model <MODEL_NAME>
myar --model <MODEL_NAME>

So, here '-model' is such an option. I want to take the input of this option only at a single place in the UI. To achieve this, I added one option (with id my.toolchain.general.model) at the tool-chain level and a corresponding "invisible" option (with id my.toolchain.compiler.model) at the tool level, as you can see in the snippet of the plugin.xml:
            name="my tool chain"
               name="Model Name"
            command="mycc -c"
            name="My Compiler"
               name="Model Name"
                  false body text

The idea here was to take the input from UI using the toolchain-level option, while use the invisible option during the generation of the command. For this, I needed to copy the input value from UI to the invisible option's value. I achieved this by attaching OptionsValueHandler to the toolchain-level option (as can be seen in plugin.xml also) and in there I implemented the copying. With this, things started working if I always open the "Build Settings" dialog before issuing the build, but in other cases, the option value was not available in the command. I tried fixing this using the commandGenerator hook in the invisible option, but then saw some other issues.

Could someone please suggest/comment that the approach I have taken is in the right direction or if there are other better/simpler approaches to tackle such options that need to passed to a number of tools in CDT Managed build mechanism?

Thanks and Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>


cdt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

End of cdt-dev Digest, Vol 127, Issue 34

Back to the top