Re: [cdt-dev] adding a toolchain with common options to tools (Warren Pa

[Ashutosh <ashutoshpal2006@xxxxxxxxx>]

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?

Thanks,

Ashutosh

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.


@Override

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:
      <toolChain
            id="my.toolchain.toolchain"
            isAbstract="true"
            name="my tool chain"
            osList="linux"
            targetTool="my.toolchain.linker">
         <option
               category="my.toolchain.general_options"
               id="my.toolchain.general.model"
               isAbstract="false"
               name="Model Name"
               resourceFilter="all"
               valueHandler="my.build.toolchain.HierarchicalOptionsValueHandler"
               valueType="string">
         </option>
      </toolChain>
      <tool
            command="mycc -c"
           id="my.toolchain.compiler"
            isAbstract="true"
            name="My Compiler"
            natureFilter="both"
            outputFlag="-o">
         <option
               category="my.toolchain.compiler.compiler_options"
               command="--model"
               commandGenerator="my.build.toolchain.HierarchicalOptionsCommandGenerator"
               id="my.toolchain.compiler.model"
               isAbstract="false"
               name="Model Name"
               resourceFilter="all"
               valueType="string">
            <enablement
                  type="CMD_USAGE">
            </enablement>
            <enablement
                  type="UI_VISIBILITY">
               <false>
                  false body text
               </false>
            </enablement>
         </option>
      </tool>


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,
Ashutosh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/cdt-dev/attachments/20150917/c6da6f3d/attachment.html>

------------------------------

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev

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