requires

Description

Configuration options are not independent. For example the C library can provide thread-safe implementations of certain functions, but only if the kernel is present, if the kernel provides multi-threading, and if the kernel options related to per-thread data are enabled. It is possible to express such constraints using requires properties.

The arguments to a requires property should constitute a goal expression, as described in the Section called List Expressions in Chapter 3. Most goal expressions are relatively simple because the constraints being described are simple, but complicated expressions can be used when necessary. The body of an option or other CDL entity can contain any number of requires constraints. If the option is active and enabled then all these constraints should be satisfied, and any goal expressions which evaluate to 0 will result in conflicts being raised. It is possible for users to ignore such conflicts and attempt to build the current configuration anyway, but there is no guarantee that anything will work. If an option is inactive or disabled then its requires constraints will be ignored.

The configuration system contains an inference engine which can resolve many types of conflicts automatically. For example, if option A is enabled and requires an option B that is currently disabled then the inference engine may attempt to resolve the conflict by enabling B. However this will not always be possible, for example there may be other constraints in the configuration which force B to be disabled at present, in which case user intervention is required.

Example

cdl_component CYGPKG_IO_SERIAL_POWERPC_COGENT_SERIAL_A {
    display       "Cogent PowerPC serial port A driver"
    flavor        bool
    default_value 0
    requires      (CYGIMP_KERNEL_INTERRUPTS_CHAIN || \
                   !CYGPKG_IO_SERIAL_POWERPC_COGENT_SERIAL_B)
    …
}

See Also

Property active_if.