Table of Contents
In a large development environment, it is very common for a developer to have a local work area that contains only the parts of the system that he or she is actually working on. Any additional parts of the software that are required in order to satisfy dependencies would be resolved through some kind of outside, most likely read-only, reference area. Abuild provides this functionality through the use of backing areas.
At first glance, backing areas may seem very similar to externals, but they are different in some important ways. As opposed to externals, backing areas are generally of more concern to baseline administrators than to developers. The uses cases for them are also different. We discuss this in more depth during this chapter.
Any build tree can be a backing area. If abuild needs to
reference a build item that is found in the local build tree or
its externals, it will use that copy of the build item. If
abuild can't find an item in the local tree or its externals,
it will use the backing area to resolve that build item. Since
abuild never attempts to build or otherwise modify an item in a
backing area, backing areas must always be fully built on all
platforms for which they will be used as backing areas. (For
additional details on platforms, please see Chapter 5, Target Types, Platform Types, and Platforms.) To designate another tree as your
backing area, create a file called
Abuild.backing in the root directory of your
build tree and place the path (which may be absolute or relative)
to the backing area in that file on a line by itself. When one
tree declares another tree as a backing area, we say that the
tree backs to its backing area. Creation
and maintenance of backing areas is generally a function
performed by the people who are in charge of maintaining the
overall software baselines. Most developers will just set up
their backing areas according to whatever instructions they are
given. Having an external tool to create your
Abuild.backing file is also reasonable.
Note that Abuild.backing files should not
generally be controlled in a version control system since they
are a property of the developer's work area rather than of the
software baseline. If they are controlled, they should generally
not be visible outside of the developer's work area.
Changing backing area configuration should generally be followed by a clean build. This is also true when a build item is removed from a local build tree and therefore causes the build item with that name to resolve to the copy in backing area. The reason is that changing the location of a build item changes the actual files on which the build target depends. If those dependencies are older than the last build time, even if they were newer than the files they replaced, make and ant will not notice because they use modification time-based dependencies. In other words, any operation that can replace one file with another file in such a way that the new file is not more recent than the last build should be followed by a clean build.