 | build 3.0.0.201402161939 |
| build 3.0.0.201402161939 |
The state of a CDL configuration option is a somewhat complicated concept. This state determines what happens when a build tree is generated: it controls what files get built and what #define's end up in configuration header files. The state also controls the values used during expression evaluation. The key concepts are:
An option may or may not be loaded into the current configuration. However it is still possible for packages to reference options which are not loaded in a requires constraint or other expression. If an option is not loaded then it will have no direct effect on the build process, and 0 will be used for expression evaluation.
Even if an option is loaded it may still be inactive. Usually this is controlled by the option's location in the configuration hierarchy. If an option's parent is active and enabled then the option will normally be active. If the parent is either inactive or disabled then the option will be inactive. For example, if kernel timeslicing is diabled then the option CYGNUM_KERNEL_SCHED_TIMESLICE_TICKS is irrelevant and must have no effect. The active_if property can be used to specify additional constraints. If an option is inactive then it will have no direct effect on the build process, in other words it will not cause any files to get built or #define's to be generated. For the purposes of expression evaluation an inactive option has a value of 0.
An option may be enabled or disabled. Most options are boolean in nature, for example a particular function may get inlined or it may involve a full procedure call. If an option is disabled then it has no direct effect on the build process, and for the purposes of expression evaluation it has a value of 0.
An option may also have additional data associated with it, for example a numerical value used to control the size of an array.
Most options are boolean in nature and do not have any additional associated data. For some options only the data part makes sense and users should be unable to manipulate the enabled/disabled part of the state. For a comparatively small number of options it makes sense to have the ability to disable that option or to enable it and associate data as well. Finally, when constructing an option hierarchy it is occasionally useful to have entities which serve only as placeholders. The flavor property can be used to control all this. There are four possible values. It should be noted that the active or inactive state of an option takes priority over the flavor: if an option is inactive then no #define's will be generated and any build-related properties such as compile will be ignored.
The none is intended primarily for placeholder components in the hierarchy, although it can be used for other purposes. Options with this flavor are always enabled and do not have any additional data associated with them, so there is no way for users to modify the option. For the purposes of expression evaluation an option with flavor none always has the value 1. Normal #define processing will take place, so typically a single #define will be generated using the option name and a value of 1. Similarly build-related properties such as compile will take effect.
Boolean options can be either enabled or disabled, and there is no additional data associated with them. If a boolean option is disabled then no #define will be generated and any build-related properties such as compile will be ignored. For the purposes of expression evaluation a disabled option has the value 0. If a boolean option is enabled then normal #define processing will take place, all build-related properties take effect, and the option's value will be 1.
Options with this flavor are always enabled, and have some additional data associated with them which can be edited by the user. This data can be any sequence of characters, although in practice the legal_values property will often be used to impose constraints. In appropriate contexts such as expressions the configuration tools will attempt to interpret the data as integer or floating point numbers. Since an option with the data flavor cannot be disabled, normal #define processing takes place and the data will be used for the value. Similarly all build-related properties take effect, and the option's value for the purposes of expression evaluation is the data.
This combines the bool and data flavors. The option may be enabled or disabled, and in addition the option has some associated data. If the option is disabled then no #define will be generated, the build-related properties have no effect, and for the purposes of expression evaluation the option's value is 0. If the option is enabled then a #define will be generated using the data as the value, all build-related properties take effect, and the option's value for the purposes of expression evaluation is the data. If 0 is legal data then it is not possible to distinguish this case from the option being disabled or inactive.
Options and components have the bool flavor by default, but this can be changed as desired. Packages always have the booldata flavor, and this cannot be changed. Interfaces have the data flavor by default, since the value of an interface is a count of the number of active and enabled interfaces, but they can be given the bool or booldata flavors.
Note: The expression syntax needs to be extended to allow the loaded, active, enabled and data aspects of an option's state to be examined individually. This would allow component writers to distinguish between a disabled booldata option and an enabled one which has a value of 0. Such an enhancement to the expression syntax may also prove useful in other circumstances.