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
|
// file : bdep/config.cli
// copyright : Copyright (c) 2014-2017 Code Synthesis Ltd
// license : MIT; see accompanying LICENSE file
include <bdep/project.cli>;
"\section=1"
"\name=bdep-config"
"\summary=manage project build configurations"
namespace bdep
{
{
"<options>
<cfg-spec> <cfg-name> <cfg-dir>
<prj-spec> <prj-dir>
<cfg-args> <option> <module> <cfg-var>",
// Other potential subcommands:
//
// list - list associated configurations
// show|status - details about a configuration (init'ed packages, etc)
//
// @@ Should we be able to remove config with init'ed packages? Who
// is going to drop them in configs? Or require them to be de-init'ed?
// A: yes, only empty configs should be removed, if not empty, suggest
// to deinitialize with bdep-deinit.
//
// @@ Should set be able to alter forward flag? This will require both
// disfiguring forward on old and configuring on new. Perhaps best
// done by sync? I.e., for this change to take effect, one has to
// run sync on both configs? Then sync would somehow need to know
// to remove forwards. Maybe it should always check for stray
// forwards (via out-root.build).
//
"\h|SYNOPSIS|
\c{\b{bdep config add} \ \ \ [<options>] [<prj-spec>] [\b{@}<cfg-name>] <cfg-dir>\n
\b{bdep config create} [<options>] [<prj-spec>] [\b{@}<cfg-name>] <cfg-dir> [<cfg-args>]\n
\b{bdep config remove} [<options>] [<prj-spec>] <cfg-spec>... | \b{--all}|\b{-a}\n
\b{bdep config rename} [<options>] [<prj-spec>] <cfg-spec> <cfg-name>\n
\b{bdep config set} \ \ \ [<options>] [<prj-spec>] <cfg-spec>\n
\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ [\b{--}[\b{no-}]\b{default}]\n
\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ [\b{--}[\b{no-}]\b{forward}]\n
\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ [\b{--}[\b{no-}]\b{auto-sync}]}
\c{<cfg-spec> = \b{@}<cfg-name> | \b{--config}|\b{-c} <cfg-dir>\n
<prj-spec> = \b{--directory}|\b{-d} <prj-dir>\n
<cfg-args> = (<option> | <module> | <cfg-var>)...}
\h|DESCRIPTION|
The \cb{config} command provides the following subcommands for managing
project's build configurations. If no project directory is specified,
then the current working directory is assumed."
}
class cmd_config_subcommands
{
"\h|CONFIG SUBCOMMANDS|
\dl|
\li|\cb{add}
|
\li|\cb{create}
The \cb{add} subcommand adds an existing \l{bpkg(1)} build
configuration in directory \ci{cfg-dir} to the project's build
configuration set. The \cb{create} subcommand creates a new
configuration in directory \ci{cfg-dir} by executing the
\l{bpkg-cfg-create(1)} command and passing to it \ci{cfg-args}, if
any. It then proceeds as \cb{add} by adding the new configuration to
the project's build configuration set.
In both subcommands, if \ci{cfg-name} is specified, then the added
configuration is given this name. Several \cb{bdep} commands can use
such names as a more convenient way to specify build configurations
(see \l{bdep-projects-configs(1)} for details).
As a shortcut, if \ci{cfg-name} is not specified and \ci{cfg-dir} is
a simple path that starts with \cb{@}, then it is treated as the name
and the configuration directory is assumed to be
\c{\i{prj-dir}\b{-}\i{cfg-name}}.
Unless the \cb{--no-default} option is specified, the first added or
created build configuration is designated as the default. Several
\cb{bdep} commands use such a configuration by default if no
configuration was specified explicitly (see
\l{bdep-projects-configs(1)} for details). To make a subsequently
added configuration the default use the \cb{--default} option.
The default build configuration is also designated as forwarded
unless the \cb{--no-forward} option is specified or another
configuration is already designated as forwarded. When a project is
initialized in a forwarded build configuration, its source directory
is configured to forward to this configuration (see \l{b(1)} for
details on forwarded configurations). To forward to a non-default
configuration use the \cb{--forward} option.
Unless the \cb{--no-auto-sync} option is specified, an added or
created build configuration will be automatically synchronized on
every build system invocation. Note that this flag affects the entire
build configuration and if multiple projects share the same
configuration, then they must have a consistent auto-synchronization
setting.|
\li|\cb{remove}
The \cb{remove} subcommand removes one or more build configurations
from the project's build configuration set. See
\l{bdep-projects-configs(1)} for various ways to specify build
configurations.|
\li|\cb{rename}
The \cb{rename} subcommand gives the specified build configuration
a new name.|
\li|\cb{set}
The \cb{set} subcommand sets various properties of the specified
build configuration. These include the
default (\c{\b{--}[\b{no-}]\b{default}}),
forward (\c{\b{--}[\b{no-}]\b{forward}}), and
auto-synchronization (\c{\b{--}[\b{no-}]\b{auto-sync}}) flags.
Note that changing any of these flags requires an explicit
\l{bdep-sync(1)} command to take effect.||"
bool add;
bool create;
bool remove;
bool rename;
bool set;
};
// Note that not all project/configuration options are valid for all
// subcommands.
//
class cmd_config_options: configuration_add_options, project_options
{
"\h|CONFIG OPTIONS|"
};
}
|
