diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/intro.cli | 27 |
1 files changed, 16 insertions, 11 deletions
diff --git a/doc/intro.cli b/doc/intro.cli index 2670455..c411256 100644 --- a/doc/intro.cli +++ b/doc/intro.cli @@ -2018,7 +2018,10 @@ source. rapidly-developed packages since for the latter you often need to track the latest version (which may not yet be available from the system repository) and/or test with multiple versions (which is not something that many system -package managers support).| +package managers support). + +We can also have some build configurations using a system-installed version of +a dependency while others building it from source, for example, for testing.| We can instruct \c{build2} to configure a dependency package as available from the system rather than building it from source. Let's see how this works in an @@ -2029,13 +2032,6 @@ The first step is to add it as a dependency, just like we did for \c{libhello}. That is, add another \c{depends} entry to \c{manifest}, then import it in \c{buildfile}, and so on. -\N|Note that the dependency still has to be packaged and available from one of -the project's prerequisite repositories. However, it can be a \i{stub} \- a -package that does not contain any source code and that can only be \"obtained\" -from the system (see \l{bpkg#package-version Package Version} for -details). See also \l{#guide-unpackaged-deps Using Unpackaged Dependencies} -for how to deal with dependencies that are not packaged.| - Now, if we just run \c{sync} or try to build our project, \c{build2} will download and build the new dependency from source, just like it did for \c{libhello}. Instead, we can issue an explicit \c{sync} command that @@ -2052,14 +2048,23 @@ Here \cb{?} is a package \i{flag} that instructs \c{build2} to treat it as a dependency and \cb{sys} is a package \i{scheme} that tells \c{build2} it comes from the system. See \l{bpkg-pkg-build(1)} for details. -\N|We can have some build configurations using a system-installed version of -a dependency while others building it from source, for example, for testing.| - \N|The system-installed dependency doesn't really have to come from the system package manager. It can also be manually installed and, as discussed in \l{#guide-unpackaged-deps Using Unpackaged Dependencies}, not necessarily into the system-default location like \c{/usr/local}.| +In the above example our dependency still has to be packaged and available +from one of the project's prerequisite repositories. But it can be a \i{stub} +\- a package that does not contain any source code and that can only be +\"obtained\" from the system (see \l{bpkg#package-version Package Version} for +details). However, if we would like to use a completely unpackaged dependency, +then we will have to specify its version explicitly either as the actual +version or as the \c{*} wildcard, for example: + +\ +$ bdep sync ?sys:libsqlite3/* ?sys:libcurl/7.47.0 +\ + \N|Currently, unless we specify the installed version explicitly, a system-installed package is assumed to satisfy any dependency constraint. In the future, \c{build2} will automatically query commonly used system package |