# NAME

`bpkg-pkg-build` – build package

# SYNOPSIS

`bpkg pkg-build|build [options] [--upgrade|-u | --patch|-p]
[cfg-var... --] pkg-spec...
bpkg pkg-build|build [options] --upgrade|-u | --patch|-p
[cfg-var... --]`

`pkg-spec = [flags](([scheme:]pkg[/ver]),...[@rep-loc] |
[@]rep-loc |
file |
dir/)
flags = ?
scheme = sys`

# DESCRIPTION

The `pkg-build` command builds one or more packages including all their dependencies. Besides building new packages, this command is also used to upgrade or downgrade packages that are already present in the configuration. And unless the `--keep-unused|-K` option is specified, `pkg-build` will also drop dependency packages that would otherwise no longer be used.

The first form (one or more packages are specified) builds new or upgrades (by default or if `--upgrade` is specified) or patches (if `--patch` is specified) the specified packages. The second form (no arguments but either `--upgrade` or `--patch` is specified) upgrades or patches all the held packages in the configuration (see below for details on held package).

In both forms specifying the `--immediate|-i` or `--recursive|-r` option causes `pkg-build` to also upgrade or patch the immediate or all dependencies of the specified (first form) or held (second form) packages, respectively. Note also that in the first form these options can only be specified with an explicit `--upgrade` or `--patch`.

Each package can be specified as just the name (`pkg`) with optional package version (`ver`) in which case the source code for the package will be automatically fetched from one of the configured repositories. See the `bpkg-rep-add(1)` and `bpkg-rep-fetch(1)` commands for more information on package repositories. If `ver` is not specified, then the latest available version will be built. To downgrade, the desired version must be specified explicitly. For example:

    bpkg build foo libfoo/1.2.3

Alternatively, the package repository location (`rep-loc`) can be specified as part of the build command. In this case, if `ver` is not specified, then the latest available from this repository version will be built. For example:

    bpkg build foo,libfoo/1.2.3@https://git.example.org/foo.git#master

If only the location is specified, then the latest versions of all the packages available directly from this repository will be built (note that this does not include packages available from complement repositories). The `@` delimiter can be omitted if the location is a URL. For example:

    bpkg build https://git.example.org/foo.git#master
    bpkg build @/path/to/repository/

A package name (`pkg`) can be prefixed with a package scheme (`scheme`). Currently the only recognized scheme is `sys` which instructs `pkg-build` to configure the package as available from the system rather than building it from source. If the system package version (`ver`) is not specified or is '`*`', then it is considered to be unknown but satisfying any dependency constraint. If the version is not explicitly specified, then at least a stub package must be available from one of the repositories.

Finally, a package can be specified as either the path to the package archive (`file`) or to the package directory (`dir``/`; note that it must end with a directory separator). See the `bpkg-pkg-fetch(1)` and `bpkg-pkg-unpack(1)` commands for more information on the semantics of specifying the package as an archive or a directory.

Additional configuration variables (`cfg-var`), if any, should be specified before packages (`pkg-spec`) and should be separated with `--`. Such variables are effective only when configuring and only for packages that were explicitly specified on the command line (they can also be specified to only apply to specific packages using the argument grouping mechanism discussed below). See `bpkg-pkg-configure(1)` for more information on configuration variables.

By default a package that is specified explicitly on the command line is built to hold: it will not be considered for automatic removal if it no longer has any dependents. Only versions from repositories that were added to the configuration (`bpkg-rep-add(1)`) are considered as available for build to hold.

Alternatively, a package can be built (or, more commonly, upgraded/downgraded) as a dependency by specifying the `?` flag (`flags`) or the `--dependency` option. Such a package will only be added to the configuration if it actually has any dependents and once no longer used, it will be automatically dropped. Only versions from prerequisite repositories of dependent packages are considered as available for build as a dependency.

Packages (both built to hold and as dependencies) that are specified with an explicit package version (`ver`) or as an archive or directory, will have their versions held, that is, they will not be automatically upgraded.

As an illustration, let's assume in the following example that the stable repository contains packages `foo` `1.0.0` as well as `libfoo` `1.0.0` and `1.1.0` while testing – `libfoo` `2.0.0`, that testing is complemented by stable, and that `foo` depends on `libfoo >= 1.0.0`:

    bpkg fetch https://example.org/1/testing

    bpkg build foo            # build foo    1.0.0 to hold
                              # build libfoo 1.1.0 as dependency

    bpkg build ?libfoo/1.0.0  # downgrade libfoo 1.0.0 as dependency,
                              #           also hold version 1.0.0

    bpkg build ?libfoo/2.0.0  # error: 2.0.0 unavailable in dependent's
                              #        (foo) repository (stable)

    bpkg build libfoo/2.0.0   # upgrade libfoo 2.0.0 to hold,
                              #         also hold version 2.0.0

# PKG-BUILD PACKAGE OPTIONS

The following options (as well as additional configuration variables) can be grouped to apply to a specific `pkg-spec` as well as specified globally, in which case they apply to all the specified packages (see `bpkg-argument-grouping(1)` for details).

`--upgrade`|`-u`
  Upgrade packages to the latest available version that satisfies all the constraints.
`--patch`|`-p`
  Upgrade packages to the latest available patch version that satisfies all the constraints.
`--immediate`|`-i`
  Also upgrade or patch immediate dependencies.
`--recursive`|`-r`
  Also upgrade or patch all dependencies, recursively.
`--upgrade-immediate`
  Upgrade immediate dependencies.
`--patch-immediate`
  Patch immediate dependencies.
`--upgrade-recursive`
  Upgrade all dependencies, recursively.
`--patch-recursive`
  Patch all dependencies, recursively.
`--dependency`
  Build, upgrade, or downgrade a package as a dependency rather than to hold.
`--keep-out`
  Keep output directories of external packages between upgrades and downgrades. Refer to `bpkg-pkg-disfigure(1)` for details.

# PKG-BUILD GLOBAL OPTIONS

`--yes`|`-y`
  Assume the answer to all prompts is `yes`.
`--for`|`-f` `operation`
  Instead of the default `update` build system operation, perform the `update-for-``operation` variant where `operation` is normally `install` or `test`.
`--keep-unused`|`-K`
  Don't drop dependency packages that were automatically built but will no longer be used.
`--update-dependent`|`-U`
  Update without confirmation dependent packages that are reconfigured due to their dependencies being upgraded or downgraded.
`--leave-dependent`|`-L`
  Don't offer to update dependent packages that are reconfigured due to their dependencies being upgraded or downgraded.
`--configure-only`|`-c`
  Configure all the packages but don't update.
`--print-only`|`-p`
  Print to `stdout` what would be done without actually doing anything.
`--plan` `header`
  Print the plan (even if `--yes` is specified) and start it with the `header` line (unless it is empty).
`--no-fetch`
  Don't fetch repositories specified as part of the build command.
`--fetch-shallow`
  Don't re-fetch complement and prerequisite repositories of repositories specified as part of the build command. Refer to the `--shallow` option in `bpkg-rep-fetch(1)` for details.
`--directory`|`-d` `dir`
  Assume configuration is in `dir` rather than in the current working directory.

# COMMON OPTIONS

The common options are summarized below with a more detailed description available in `bpkg-common-options(1)`.

`-v`
  Print essential underlying commands being executed.
`-V`
  Print all underlying commands being executed.
`--quiet`|`-q`
  Run quietly, only printing error messages.
`--verbose` `level`
  Set the diagnostics verbosity to `level` between 0 and 6.
`--jobs`|`-j` `num`
  Number of jobs to perform in parallel.
`--no-result`
  Don't print informational messages about the outcome of performing a command.
`--no-progress`
  Suppress progress indicators for long-lasting operations, such as network transfers, building, etc.
`--build` `path`
  The build program to be used to build packages.
`--build-option` `opt`
  Additional option to be passed to the build program.
`--fetch` `path`
  The fetch program to be used to download resources.
`--fetch-option` `opt`
  Additional option to be passed to the fetch program.
`--fetch-timeout` `sec`
  The fetch and fetch-like (for example, `git`) program timeout.
`--git` `path`
  The git program to be used to fetch git repositories.
`--git-option` `opt`
  Additional common option to be passed to the git program.
`--sha256` `path`
  The sha256 program to be used to calculate SHA256 sums.
`--sha256-option` `opt`
  Additional option to be passed to the sha256 program.
`--tar` `path`
  The tar program to be used to extract package archives.
`--tar-option` `opt`
  Additional option to be passed to the tar program.
`--openssl` `path`
  The openssl program to be used for crypto operations.
`--openssl-option` `opt`
  Additional option to be passed to the openssl program.
`--auth` `type`
  Types of repositories to authenticate.
`--trust` `fingerprint`
  Trust repository certificate with a SHA256 `fingerprint`.
`--trust-yes`
  Assume the answer to all authentication prompts is `yes`.
`--trust-no`
  Assume the answer to all authentication prompts is `no`.
`--pager` `path`
  The pager program to be used to show long text.
`--pager-option` `opt`
  Additional option to be passed to the pager program.
`--options-file` `file`
  Read additional options from `file`.

# BUGS

Send bug reports to the users@build2.org mailing list.