Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Problem with Enumerated Option Values and Option References in the Managed Build Model

Two of the attributes of every "Enumerated Option Value" are:

id : A unique identifier for the tool that will be used by the build model.

name : A descriptive name that will be displayed to the user in the UI as one of the option values to select.

These are fine.  However, I've found something in the "Option Reference" implementation for enumerated options that I would consider a "bug".  

Every Option Reference has the attribute:

defaultValue : For boolean and string options, this field is used to hold the value entered by the user. For enumerated options, it is used to hold the selected enumerated option value. For list options, this attribute is not used.
 
Note the description for enumerated options, "it is used to hold the selected enumerated option value".  I've discovered empirically that the defaultValue attribute for enumerated options contains the value of the Enumerated Option Value NAME attribute.  It should contain the ID attribute.  The reason is that the NAME attribute is used in the UI to describe the option and can easily change:

1.  Because we discover a better way to describe the option value
2.  Because of localization work.

If the NAME attribute changes, then all existing projects that have overridden the Enumerated Option are broken.  The string in their .cdtbuild file no longer matches the NAME in the Toolchain description.

Because of this, the ID value should be used instead.  The ID value never NEEDS to change, and any tool provider who does change it better understand the consequences.

For the sake of upward compatibility of 1.2 projects, the code that matches an enumerated option value reference could be coded to search first for an ID match, and if that fails to search for a NAME match.  

If the group agrees that this is a bug, I can enter a bugzilla report.  I am also willing to work on the patch for this - just give me the go-ahead...

Leo Treggiari
Intel Corp.


Back to the top