calculated

Description

In some cases it is useful to have a configuration option whose value cannot be modified directly by the user. This can be achieved using a calculated, which takes a CDL expression as argument (see the Section called Ordinary Expressions in Chapter 3 for a description of expression syntax). The configuration system evaluates the expression when the current package is loaded and whenever there is a change to any other option referenced in the expression. The result depends on the option's flavor:

There are a number of valid uses for calculated options, and there are also many cases where some other CDL facility would be more appropriate. Valid uses of calculated options include the following:

• On some target hardware a particular feature may be user-configurable, while on other targets it is fixed. For example some processors can operate in either big-endian or little-endian mode, while other processors do not provide any choice. It is possible to have an option CYGARC_BIGENDIAN which is calculated in some architectural HAL packages but user-modifiable in others.

• Calculated options can provide an alternative way for one package to affect the behavior of another one. Suppose a package may provide two possible implementations, a preferred one involving self-modifying code and a slower alternative. If the system involves a ROM bootstrap then the slower alternative must be used, but it would be inappropriate to modify the startup option in every HAL to impose constraints on this package. Instead it is possible to have a calculated option whose value is { CYG_HAL_STARTUP == "ROM" }, and which has appropriate consequences. Arguably this is a spurious example, and it should be a user choice whether or not to use self-modifying code with a default_value based on CYG_HAL_STARTUP, but that is for the component writer to decide.

• Sometimes it should be possible to perform a particular test at compile-time, for example by using a C preprocessor #if construct. However the preprocessor has only limited functionality, for example it cannot perform string comparisons. CDL expressions are more powerful.

• Occasionally a particular sub-expression may occur multiple times in a CDL script. If the sub-expression is sufficiently complex then it may be worthwhile to have a calculated option whose value is the sub-expression, and then reference that calculated option in the appropriate places.

Alternatives to using calculated options include the following:

• CDL interfaces are a form of calculated option intended as an abstraction mechanism. An interface can be used to express the concept of any scheduler, as opposed to a specific one such as the bitmap scheduler.

• If a calculated option would serve only to add additional information to a configuration header file, it may be possible to achieve the same effect using a define_proc property or one of the other properties related to header file generation.

Example

# A constant on some target hardware, perhaps user-modifiable on other
# targets.
cdl_option CYGNUM_HAL_RTC_PERIOD {
    display       "Real-time clock period"
    flavor        data
    calculated    12500
}

See Also

Properties default_value, flavor and legal_values,