Table of Contents
Management of dependencies among build items is central to abuild's functionality. We have already gotten a taste of this capability in the basic examples included in Chapter 3, Basic Operation. In this chapter, we will examine dependencies in more depth.
The sole mechanism for declaring dependencies among build items
in abuild is the deps key in a build
item's Abuild.conf. Suppose build item
A declares build item
B as a dependency. The following line
would appear in A's
Abuild.conf:
deps: B
This declaration causes two things to happen:
It ensures that B will be built before
A.
It enables A to see all of the variable
declarations and assignments in B's
Abuild.interface file.
We illustrate both of these principles later in this chapter. For an in-depth discussion of build ordering and dependency-aware builds, see Chapter 9, Telling Abuild What to Build. For an in-depth discussion of abuild's interface system, see Chapter 17, The Abuild Interface System.
Another very important point about dependencies in abuild is
that they are transitive. In other words,
if A depends on B
and B depends on C,
then A also implicitly depends on
C. This means that the conditions above
apply to A and C.
That is, C is built before
A (which it would be anyway since it is
built before B and
B is built before
A), and A sees
C's interface in addition to seeing
B's interface.
[14]
Assuming that
A does not explicitly list
C in its deps key, we
would call B a direct
dependency of A and
C an indirect
dependency of A. We also say
that build item dependencies are inherited
when we wish to refer to the fact that build ordering and
interface visibility are influenced by both direct and indirect
dependencies.
Abuild performs various validations on dependencies. The most
important of these is that no cyclic dependencies are permitted.
[15]
In other words, if A depends on
B either directly or indirectly, then
B cannot depend on
A directly or indirectly. There are other
dependency validations which are discussed in various places
throughout this document.
By default, any build item can depend on any other build item by name. Abuild offers two mechanisms to restrict which items can depend on which other items. One mechanism is through build item name scoping rules, discussed below. The other mechanism is through use of multiple build trees, discussed in Chapter 7, Multiple Build Trees.
[14]
In fact, since B depends on
C, C's interface
is effectively included as part of B's
interface. This makes C's interface
visible to all build items that depend on
B. The exact mechanism by which this
works is described in Chapter 17, The Abuild Interface System.
[15] Stated formally, abuild requires that build item dependencies form a directed acyclic graph.