calculated

Name

Property calculated -- Used if the current option's value is not user-modifiable, but is calculated using a suitable CDL expression.

Synopsis

cdl_option <name> {
    calculated <expression>
    …
}

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:

flavor none

Options with this flavor have no value, so the calculated property is not applicable.

flavor bool

If the expression evaluates to a non-zero result the option is enabled, otherwise it is disabled.

flavor booldata

If the result of evaluating the expression is zero then the option is disabled, otherwise the option is enabled and its value is the result.

flavor data

The value of the option is the result of evaluating the expression.

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:

Alternatives to using calculated options include the following:

Tip: If the first entry in a calculated expression is a negative number, for example calculated -1 then this can be misinterpreted as an option instead of as part of the expression. Currently the calculated property does not take any options, but this may change in future. Option processing halts at the sequence --, so the desired value can be expressed safely using calculated -- -1

Warning

Some of the CDL scripts in current eCos releases make excessive use of calculated options. This is partly because the recommended alternatives were not always available at the time the scripts were written. It is also partly because there is still some missing functionality, for example define_proc properties cannot yet access the configuration data so it may be necessary to use calculated properties to access the data and perform the desired manipulation via a CDL expression. New scripts should use calculated options only in accordance with the guidelines.

Note: For options with the booldata flavor the current CDL syntax does not allow the enabled flag and the value to be calculated separately. Functionality to permit this may be added in a future release.

Note: It has been suggested that having options which are not user-modifiable is potentially confusing, and that a top-level cdl_constant command should be added to the language instead of or in addition to the calculated property. Such a change is under consideration. However because the value of a calculated option can depend on other options, it is not necessarily constant.

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,