|
1 ======== |
|
2 Glossary |
|
3 ======== |
|
4 |
|
5 .. glossary:: |
|
6 :sorted: |
|
7 |
|
8 object directory |
|
9 A directory holding the output of the build system. The build |
|
10 system attempts to isolate all file modifications to this |
|
11 directory. By convention, object directories are commonly |
|
12 directories under the source directory prefixed with **obj-**. |
|
13 e.g. **obj-firefox**. |
|
14 |
|
15 mozconfig |
|
16 A shell script used to configure the build system. |
|
17 |
|
18 configure |
|
19 A generated shell script which detects the current system |
|
20 environment, applies a requested set of build configuration |
|
21 options, and writes out metadata to be consumed by the build |
|
22 system. |
|
23 |
|
24 config.status |
|
25 An executable file produced by **configure** that takes the |
|
26 generated build config and writes out files used to build the |
|
27 tree. Traditionally, config.status writes out a bunch of |
|
28 Makefiles. |
|
29 |
|
30 install manifest |
|
31 A file containing metadata describing file installation rules. |
|
32 A large part of the build system consists of copying files |
|
33 around to appropriate places. We write out special files |
|
34 describing the set of required operations so we can process the |
|
35 actions effeciently. These files are install manifests. |
|
36 |
|
37 clobber build |
|
38 A build performed with an initially empty object directory. All |
|
39 build actions must be performed. |
|
40 |
|
41 incremental build |
|
42 A build performed with the result of a previous build in an |
|
43 object directory. The build should not have to work as hard because |
|
44 it will be able to reuse the work from previous builds. |
|
45 |
|
46 mozinfo |
|
47 An API for accessing a common and limited subset of the build and |
|
48 run-time configuration. See :ref:`mozinfo`. |