Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] [CDT MBS (Managed Build System)] Inheritance problem with Option

Hi Jonah,

Thanks for the answer.
I have better grasp the problem. I provide you in attached file a plugin to easily reproduce the behavior because there is some aspect that requires custom config.

Actually, the problem is how to define the option under the toolchain element in the extension point org.eclipse.cdt.managedbuilder.core.buildDefinitions.
If you define an option (& the associated optionCategory) directly under the toolchain element and not under a tool element, an inheritance problem can appears. 

My plugin allows you to create a project with my own toolchain.
Please follow these steps to reproduce the problem:
1) Create a new C project, select "Others -> Example Executable" in project type panel. Then click on finish.
2) Open the property "C/C++ Build" -> "Settings" of the project
   Change the "General" option value to "non persistant value 2"
   and Apply the changes.
3) Click on "Compiler" and check that the option "All options" should be equals to "-mnonPersistent-opt=value2"
   Close the properties
4) Create a folder inside the project
   Right click on this folder and open the properties "C/C++ Build" -> "Settings".
   First point the "General" option is no longer visible in the left panel but the "non persistent value" option is still "value2" in "All options"
5) Click on "Optimization" in the left panel and tick the checkbox "useless option" ;-)
   Apply the changes, close the property and close the project.
6) Re-open the project, re-open the properties for the folder and not for the project!
   the option "all options" has changed!!! --> "-mnonPersistent-opt=value1"
   But if you check the same option via the project properties then the value is "value2".
Because of during the parsing of the xml cproject, it can not retrieve the option "non persistent option" and so applies the default value defined in the extension point that is "value1".

Note that:
 - if the valueType of the option is something other than enumerated value then the option just disappearing in "all option"
 - I would prefer not to define this option under compiler tool because this option is used by several tools.
 - In my plugin.xml, there is an other commented option defined this time under compiler tool (if you want to test the difference)


2017-02-21 14:29 GMT+01:00 Jonah Graham <jonah@xxxxxxxxxxxxxxxx>:
Hi Florent,

I have tried to reproduce your test case, but as yet have not managed.

Rather than dealing with pretend options, would it be possible to
reproduce this problem with GNU GCC toolchain as delivered with CDT
already? Or is there some aspect of this that requires custom config.

What I tried was using pedantic and the optimization enum option to reproduce.

A couple of notes:
1) If you can create a junit test case that would be the best result.
Perhaps adding it here
2) In your example the child option is called myOtpion instead of
myOption. I assume this was a typo in the email, but if not could that
indicate a further problem?


Jonah Graham
Kichwa Coders Ltd.

On 2 February 2017 at 10:04, Florent Vion <florent.vion@xxxxxxxxx> wrote:
> Hi,
> I have an inheritance issue with the value of an option defined under a
> toolchain, this option is an enumerated option with 3 values: A (default
> value), B and C.
> ## test case:
> 1) I create a project where the value for this option is B.
> 2) I create a new folder "plop" inside my project and I set the pedantic
> option only for this folder.
>    The pedantic option is not relevant, it is just to create a new tag
> folderInfo in the cproject file.
>    So at this point in the cproject file, I have two folderInfo. A parent
> folderInfo for all the project and a child just for the plop folder.
> 3) if I check the property of the plop folder, the option value is still B
> --> inheritance works, good so far!
> 4) I close/reopen project
> 5) When I check again the property of the plop folder, the option is now the
> default value A.
> ## Env:
> cproject file:
>         <configuration ...">
>                 <folderInfo id="myfolderInfo.776789828." name="/" resourcePath="">
>                         <toolChain id="myToolchain.165714716" name="my toolchain"
> superClass="my.superclass.toolchain">
>                                 ...
>                                 <option id="myOption.853101675" name="my option"
> superClass="my.superclass.option" value="B" valueType="enumerated"/>
>                                 ...
>                         </toolChain>
>                 </folderInfo>
>                 <folderInfo id="myfolderInfo.776789828.123765028" name="/"
> resourcePath="plop">
>                         <toolChain id="myToolchain.1832164238" name="my toolchain"
> superClass="my.superclass.toolchain" unusedChildren="">
>                                 ...
>                                 <option id="myOtpion.853101675.1215255250" name="my option"
> superClass="myOption.853101675"/>
>                                 <tool id="myTool.2019819561" name="my tool"
> superClass="my.superclass.tool.400362476">
>                                         <option id="gnu.c.compiler.option.warnings.pedantic.760615677"
> name="Pedantic (-pedantic)"
> superClass="gnu.c.compiler.option.warnings.pedantic" value="true"
> valueType="boolean"/>
>                                         ...
>                                 </tool>
>                                 ...
>                         </toolChain>
>                 </folderInfo>
>                 ...
>         </configuration>
> ## Issue:
> During the creation of the options, the specific option "myOption.853101675"
> (in the first folderInfo) is well created and stored in a specific Map
> (optionMap).
> But for the option "myOtpion.853101675.1215255250" (second folderInfo), its
> superClass is not found so the option is not created correctly by the end
> the value is not inherited.
> At first sight: the cproject file has been correctly created, the problem
> seems to be related to the creation of the options during the parsing of the
> xml.
> ## Debug Flow:
> Plugin cdt.managedbuilder.internal.core, in the Toolchain's constructor, for
> each children of ICStorageElement we call the loadChild method:
>         public ToolChain(IFolderInfo parentFldInfo, ICStorageElement element,
> String managedBuildRevision) {
>                 ...
>                 // Load children
>                 ICStorageElement configElements[] = element.getChildren();
>                 for (int i = 0; i < configElements.length; ++i) {
>                         ICStorageElement configElement = configElements[i];
>                         if (loadChild(configElement)) {
>                 ...
> In the loadChild method, if the children corresponds to an Option object, it
> is created and added in the map "optionMap" declared in HoldsOption class.
>         protected boolean loadChild(ICStorageElement element) {
>                 if (element.getName().equals(IHoldsOptions.OPTION)) {
>                         Option option = new Option(this, element);
>                         addOption(option);  //========================> Important for my issue
> (map OptionMap)
> During the creation of the Option object, it get the superclass via the map
> "extensionOptionMap" declared in ManagedBuildManager class:
>                 // superClass
>                 superClassId =
> SafeStringInterner.safeIntern(element.getAttribute(IProjectType.SUPERCLASS));
>                 if (superClassId != null && superClassId.length() > 0) {
>                         superClass = ManagedBuildManager.getExtensionOption(superClassId);
> //========================> Important for my issue (map extensionOptionMap)
>                         if (superClass == null) {
>                                 // TODO:  Report error
>                         }
>                 }
> Like I said above, regarding first folderInfo option, the superclass is
> found in extensionOptionMap. So after the creation of the option, it is
> added to optionMap.
> But regarding second folderInfo, the superClass is not found because this
> previous superclass was not added in extensionOptionMap but in optionMap.
> So the superclass is null, it can't retrieve the value B and in the end it
> takes the default value A.
> If you have read this far, thanks to you ;).
> ## Question:
> Do you know why a new created option is added in optionMap and not in
> extensionOptionMap?
> Feel free to comment.
> Regards,
> Florent
> --
> View this message in context:
> Sent from the Eclipse CDT - Development mailing list archive at
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
cdt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Description: Zip archive

Back to the top