Table of Contents
In widely distributed systems, it is often the case that a particular component may be able to be configured to work in different ways depending on whether some optional functionality is present. There are many ways to support this in any given software system, including having optional capabilities register themselves with some consumer of those capabilities as with our mixed classification example (see Section 25.2, “Mixed Classification Example”). There are some situations where, for whatever reason, the onus of determining how to behave must lie completely with the consumer of an optional capability rather than the supplier of the capability. This could happen if, for example, the supplier of the capability is completely unaware of the consumer. It could also happen if, because of the way the software is architected, the logic of how the consumer uses the producer must like with the consumer. To support these cases, abuild supports the use of optional dependencies.
Both item dependencies and tree dependencies may be declared as
optional by placing the -optional
option after
the item or tree name in the deps or
tree-deps declaration in the
Abuild.conf
file. If an optional tree
dependency is not found, abuild simply ignores the optional
tree dependency. If an optional item dependency is declared,
abuild will create a local (non-inheriting) boolean interface
variable called
ABUILD_HAVE_OPTIONAL_DEP_
where item
item
is the name of the item
that was declared as an optional dependency. If the optional
dependency is found, this variable will have a true value, and
abuild will process the dependency normally. If the optional
dependency is not found, this variable will have a false value,
and abuild will otherwise ignore the optional dependency.
Sometimes an optional dependency may be satisfied by a build item
or tree that may not always be present. In this case, you may
find that using -optional
when listing the child
directory that contains the item or tree when it's present makes
it possible to use the exact same abuild configuration whether
or not the optional item is present. With this mode of use, a
capability may be turned on or off simply by including or
excluding a particular directory in a build. Although there are
certainly valid scenarios for this style of operation, this
feature has a high potential for abuse, so you should consider
carefully whether it is the right solution to your problem. It
is possible to create software that may behave differently based
on combinations of presence or absence of optional features.
Such software can become very difficult to maintain and test.
Ideally, if you have optional capabilities that are configured in
this way, they should be lightweight and independent from each
other. However, abuild leaves this choice up to you and
provides you with this capability. You are, of course, free to
use it or not as you choose.