Skip to main content

The defaultValue definition

note

Work in progress.

Purpose

Specify a default value for this option using an xCDL expression.

Syntax

{
"cdlOptions": {
"<name>": {
...
"defaultValue": true | false | "<expression>",
...
}
}
}

The value of the defaultValue property is a boolean constant or a string containing an expression that is evaluated each time valueOf(object) is called.

Default value

If missing, the object default value depends on the object type and state:

  • none - these object have no value, and the defaultValue is not applicable
  • bool - enabled objects have the value true and non enabled objects have the value false
  • int - enabled objects have the value 1 and non enabled objects have the value 0
  • float - enabled objects have the value 1.0 and non enabled objects have the value 0.0
  • string - enabled objects have the value "1" and non enabled objects have the value "0"

Description

The defaultValue property usually defines the default value for the object with data, in case no other value is set during configuration.

The data of the defaultValue property is an xCDL expression; see the Section called Ordinary Expressions in xCDL packages for the syntactic details. In many cases a simple constant value will suffice.

However it is also possible for an object's default value to depend on other objects. For example the common HAL package provides some support functions needed by the kernel, but are unlikely to be useful if the kernel is not being used.

An object can have either a computed or a defaultValue property. If an object does not have either a defaultValue or a computed property and it does not have the valueType none then the configuration tools will assume a default value expression of 1/true if the object is enabled and 0/false otherwise.

Occasionally, it is useful to have a configuration object A that has both a requires constraint on some other object B and a defaultValue expression of B. If option B is not enabled then A will also be disabled by default and no conflict arises. If B is enabled then A also becomes enabled, and again no conflict arises. If a user attempts to enable B but not A then there will be a conflict. Users should be able to deduce that the two options are closely interlinked and should not be manipulated independently except in very unusual circumstances.

Example

The HAL option replicates the kernel option.

{
"cdlOptions": {
"thread-support": {
"parent": "hal/debug/gdb",
"display": "Include GDB multi-threading debug support",
"generatedDefinition": "OS_DEBUG_HAL_DEBUG_GDB_THREAD_SUPPORT",
"requires": "isEnabled('kernel/debug/gdb/thread-support')",
"defaultValue": "valueOf('kernel/debug/gdb/thread-support')"
}
}
}

See also

eCos reference