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, read-only reference area. Abuild provides this functionality through the use of backing areas.
Backing areas operate at the build forest level. Any build forest can act as a backing area. If abuild needs to reference a build item that is found in the local forest, it will use that copy of the build item. If abuild can't find an item in the local forest, 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.)
A build forest may declare multiple backing areas. To specify
the location of your backing areas, create a file called
Abuild.backing in the root directory of your
build forest. As with the Abuild.conf file,
the Abuild.backing file consists of
colon-separated key/value pairs. The
backing-areas key is followed by a
space-separated list of paths to your backing areas. Backing
area paths may be specified as either absolute or relative paths.
The path you declare as a backing area may point anywhere into
the forest that you wish to use as the backing area. It doesn't
have to point to the root of the forest, and it doesn't have to
point to a place in the forest that corresponds to the root of
your forest.
When one forest declares another forest as a backing area, we say
that the forest 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.