A build tree, as defined before, is a collection of build items arranged hierarchically in the file system. A build tree is formed as a result of the items it contains holding references to the locations of their parents and children within the file system hierarchy. These locations are named as relative paths in the parent-dir and child-dirs keys of the items' Abuild.conf files. Ordinarily, the value of the parent-dir key is “..”, but it doesn't have to be. It is also customary to have the value of child-dirs contain single path elements (i.e.just a file without a directory), but this is also not a hard restriction. When abuild starts up, it looks for an Abuild.conf in the current directory and looks for its parent-dir key. Using that, it locates the parent build item's Abuild.conf file and reads it for its parent-dir key. This process is repeated until abuild discovers a build item that does not have a parent-dir key. This build item is known as the root build item of the build tree.

Note that the hierarchy defined by the layout of build items in the file system is a file system hierarchy and nothing more. It doesn't have to have any bearing at all on the dependency relationships among the build items. ^[8] That said, it is sensible to organize build items in a manner that relates to the architecture of the system, and this in turn usually has implications about dependencies. Still, it is important to keep in mind that abuild is not file-system driven but rather is dependency driven.

In addition to containing build items, build trees can contain other attributes. Among these are references to other build trees, a list of supported traits, and a list of plugins. We will discuss these topics later in the document. Most of a build tree's attributes appear in the root build item's Abuild.conf file.