Chapter 28. Optional Dependencies

Table of Contents

28.1. Using Optional Dependencies
28.2. Optional Dependencies Example

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.

28.1. Using 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_item where 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.