1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
|
// file : bpkg/pkg-build.cli
// copyright : Copyright (c) 2014-2017 Code Synthesis Ltd
// license : MIT; see accompanying LICENSE file
include <bpkg/configuration.cli>;
"\section=1"
"\name=bpkg-pkg-build"
"\summary=build package"
namespace bpkg
{
{
"<options>
<pkg-spec> <scheme> <pkg> <ver>
<file>
<dir>
<rep-loc>",
"\h|SYNOPSIS|
\c{\b{bpkg pkg-build}|\b{build} [<options>] (<pkg-spec> | [\b{@}]<rep-loc> | <file> | <dir>/)...}
\c{<pkg-spec> = [<scheme>\b{:}]<pkg>[\b{/}<ver>][\b{,}...\b{@}<rep-loc>]\n
<scheme> \ \ = [\b{?}]\b{sys}}
\h|DESCRIPTION|
The \cb{pkg-build} command builds one or more packages including all their
prerequisites. Besides building new packages, this command is also used to
upgrade or downgrade packages that already exists in the configuration.
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 \l{bpkg-rep-add(1)} and \l{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 \cb{@} 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 also be prefixed with a package scheme
(<scheme>:). Currently the only recognized scheme is \cb{sys:} which
instructs \cb{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, then it is considered to be unknown but
satisfying any dependency constraint. Such a version is displayed as
\cb{*}. In certain cases you may want to indicate that a certain package
is available from the system but only add it to the configuration if it
is required by other packages being built. In this case you can use the
\cb{?sys:} system scheme variant.
Finally, a package can be specified as either the path to the package
archive (<file>) or to the package directory (<dir>\cb{/}; note that it
must end with a directory separator). See the \l{bpkg-pkg-fetch(1)} and
\l{bpkg-pkg-unpack(1)} commands for more information on the semantics of
specifying the package as an archive or a directory.
Packages that are specified explicitly on the command line will be
\i{held}, that is, they will not be considered for automatic removal if
they no longer have any dependents. Packages that are specified with the
explicit package version (<ver>) or as an archive or directory, will, in
addition, have their versions held, that is, they will not be
automatically upgraded.
The \cb{pkg-build} command also supports several options (described
below) that allow you to control the amount of work that will be done."
}
class pkg_build_pkg_options
{
"\h|PKG-BUILD PACKAGE OPTIONS|
The following options can be grouped to apply to a specific package as
well as specified globally, in which case they apply to all the specified
packages."
bool --dependency
{
"Build, upgrade, or downgrade a package as a dependency rather than to
hold."
}
bool --keep-out
{
"Keep output directories of external packages between upgrades and
downgrades. Refer to \l{bpkg-pkg-disfigure(1)} for details."
}
};
class pkg_build_options: configuration_options,
pkg_build_pkg_options
{
"\h|PKG-BUILD GLOBAL OPTIONS|"
bool --yes|-y
{
"Assume the answer to all prompts is \cb{yes}."
}
string --for|-f
{
"<operation>",
"Instead of the default \cb{update} build system operation, perform the
\cb{update-for-}<operation> variant where <operation> is normally
\cb{install} or \cb{test}."
}
bool --drop-prerequisite|-D
{
"Drop without confirmation prerequsite packages that were automatically
built and will no longer be necessary."
}
bool --keep-prerequisite|-K
{
"Don't offer to drop prerequsite packages that were automatically built
and will no longer be necessary."
}
bool --update-dependent|-U
{
"Update without confirmation dependent packages that are reconfigured
due to their prerequisites being upgraded or downgraded."
}
bool --leave-dependent|-L
{
"Don't offer to update dependent packages that are reconfigured due to
their prerequisites being upgraded or downgraded."
}
bool --configure-only|-c
{
"Configure all the packages but don't update."
}
bool --print-only|-p
{
"Print to \cb{STDOUT} what would be done without actually doing
anything."
}
bool --no-fetch
{
"Don't fetch repositories specified as part of the build command."
}
bool --fetch-shallow
{
"Don't re-fetch complement and prerequisite repositories of repositories
specified as part of the build command. Refer to the \cb{--shallow}
option in \l{bpkg-rep-fetch(1)} for details."
}
};
}
|
