diff options
Diffstat (limited to 'doc/manual.cli')
| -rw-r--r-- | doc/manual.cli | 26 |
1 files changed, 13 insertions, 13 deletions
diff --git a/doc/manual.cli b/doc/manual.cli index 8d7dc59..7dac6b0 100644 --- a/doc/manual.cli +++ b/doc/manual.cli @@ -394,14 +394,14 @@ may need to negotiate a configuration among several dependents of a package which requires it to know this package's configuration variable types and default values. -To solve this chicken and egg of a problem, \c{bpkg} includes a minimal subset -of the build system files along with the package's standard metadata (name, -version, etc) into the repository metadata (\l{#manifest-package-list-pkg -\c{packages.manifest}}). This subset is called the package build system -skeleton, or just package skeleton for short, and includes the -\c{build/bootstrap.build} and \c{build/root.build} files (or their alternative -naming scheme variants) as well as any files that may be sources by -\c{root.build}. +To solve this chicken and egg kind of problem, \c{bpkg} includes a minimal +subset of the build system files along with the package's standard metadata +(name, version, etc) into the repository metadata +(\l{#manifest-package-list-pkg \c{packages.manifest}}). This subset is called +the package build system skeleton, or just package skeleton for short, and +includes the \c{build/bootstrap.build} and \c{build/root.build} files (or +their alternative naming scheme variants) as well as any files that may be +sources by \c{root.build}. The inclusion of \c{build/bootstrap.build} and \c{build/root.build} (if present) as well as any \c{build/config/*.build} (or their alternative naming @@ -414,7 +414,7 @@ Inside these buildfiles the skeleton load can be distinguished from normal load by examining the \c{build.mode} variable, which is set to \c{skeleton} during the skeleton load. In particular, this variable must be used to omit loading of build system modules that are neither built-in nor standard -pre-installed and which are therefore listed as a package dependencies. Such +pre-installed and which are therefore listed as package dependencies. Such modules are not yet available during the skeleton load. For example: \ @@ -511,7 +511,7 @@ libfoo ^1.0.0 The configuration negotiation algorithm can be summarized as cooperative refinement. Specifically, whenever a \c{prefer} clause of a dependent changes -any configuration value, all other dependent's \c{prefer} clauses are +any configuration value, all other dependents' \c{prefer} clauses are re-evaluated. This process continues until there are no more changes (success), one of the \c{accept} clauses returned \c{false} (failure), or the process starts \"yo-yo'ing\" between two or more configurations (failure). @@ -1761,7 +1761,7 @@ $ bpkg build libhello ?libmariadb \N|While \c{bpkg}'s refusal to automatically pick an alternative that would require building a new package may at first seem unfriendly to the user, practical experience shows that such extra user-friendliness would rarely -justifies the potential confusion that it may cause. +justify the potential confusion that it may cause. Also note that it's not only the user that can pick a certain alternative but also a dependent package. Continue with the above example, if we had \c{hello} @@ -1917,7 +1917,7 @@ context expression that should evaluate to \c{true} or \c{false}, similar to \c{enable}. Given the \c{require} and \c{prefer}/\c{accept} clauses of all the dependents -of a particular dependency, \c{bpkg} tries to negotiates a configuration +of a particular dependency, \c{bpkg} tries to negotiate a configuration acceptable to all of them as described in \l{#dep-config-negotiation Dependency Configuration Negotiation}. @@ -1973,7 +1973,7 @@ dependent's configuration variables. <reflect-var> = <config-var> '=' <value> \ -The package requirements (other than other packages). Such requirements are +The package requirements other than other packages. Such requirements are normally checked in an ad hoc way during package configuration by its \c{buildfiles} and the primary purpose of capturing them in the manifest is for documentation. However, there are some special requirements that are |