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
180
181
|
---
layout: documentation
title: Command-Line Reference
---
<h1>Command-Line Reference</h1>
<pre>
bazel [<startup options>] <command> [<args>]
</pre>
or
<pre>
bazel [<startup options>] <command> [<args>] -- [<target patterns>]
</pre>
<h2>Option Syntax</h2>
<p>
Options can be passed to Bazel in different ways. Options that require a value
can be passed with either an equals sign or a space:
<pre>
--<option>=<value>
--<option> <value>
</pre>
Some options have a single character short form; in that case, the short form
has to be passed with a single dash and a space.
<pre>
-<short_form> <value>
</pre>
</p>
<p>
Boolean options can be enabled as follows:
<pre>
--<option>
--<option>=[true|yes|1]
</pre>
and disabled as follows:
<pre>
--no<option>
--<option>=[false|no|0]
</pre>
</p>
<p>
Tristate options are usually set to automatic by default, and can be
force-enabled as follows:
<pre>
--<option>=[true|yes|1]
</pre>
or force-disabled as follows:
<pre>
--no<option>
--<option>=[false|no|0]
</pre>
</p>
<h2>Target Pattern Syntax</h2>
<p>
A target pattern refers to a single or more targets, which are source files,
output files, or rules specified in BUILD files. In addition to plain labels,
Bazel also supports working-directory-relative labels, recursive patterns, and
target subtraction.
</p>
<p>
All target patterns starting with '//' are resolved relative to the current
workspace.
<table>
<tr>
<td><code>//foo/bar:wiz</code></td>
<td>Just the single target '//foo/bar:wiz'.</td>
</tr>
<tr>
<td><code>//foo/bar</code></td>
<td>Equivalent to '//foo/bar:bar'.</td>
</tr>
<tr>
<td><code>//foo/bar:all</code></td>
<td>All rules in the package 'foo/bar'.</td>
</tr>
<tr>
<td><code>//foo/...</code></td>
<td>All rules in all packages beneath the directory 'foo'.</td>
</tr>
<tr>
<td><code>//foo/...:all</code></td>
<td>All rules in all packages beneath the directory 'foo'.</td>
</tr>
<tr>
<td><code>//foo/...:*</code></td>
<td>All targets (rules and files) in all packages beneath the directory 'foo'.</td>
</tr>
<tr>
<td><code>//foo/...:all-targets</code></td>
<td>All targets (rules and files) in all packages beneath the directory 'foo'.</td>
</tr>
</table>
</p>
<p>
Targets with <code>tags=["manual"]</code> are not included in wildcard
target patterns (<code>...</code>, <code>:*</code>, <code>:all</code>, etc).
Specify such test targets with explicit labels on the command line if
you want Bazel to build/test them.
</p>
<p>
Target patterns which do not begin with '//' are resolved relative to the
current <em>working directory</em>. These examples assume a working directory of
'foo':
<table>
<tr>
<td><code>:foo</code></td>
<td>Equivalent to '//foo:foo'.</td>
</tr>
<tr>
<td><code>bar:wiz</code></td>
<td>Equivalent to '//foo/bar:wiz'.</td>
</tr>
<tr>
<td><code>bar/wiz</code></td>
<td>Equivalent to:
'//foo/bar/wiz:wiz' if foo/bar/wiz is a package,
'//foo/bar:wiz' if foo/bar is a package,
'//foo:bar/wiz' otherwise.
</td>
</tr>
<tr>
<td><code>bar:all</code></td>
<td>Equivalent to '//foo/bar:all'.</td>
</tr>
<tr>
<td><code>:all</code></td>
<td>Equivalent to '//foo:all'.</td>
</tr>
<tr>
<td><code>...:all</code></td>
<td>Equivalent to '//foo/...:all'.</td>
</tr>
<tr>
<td><code>...</code></td>
<td>Equivalent to '//foo/...:all'.</td>
</tr>
<tr>
<td><code>bar/...:all</code></td>
<td>Equivalent to '//foo/bar/...:all'.</td>
</tr>
</table>
</p>
<p>
By default, directory symlinks are followed for recursive target patterns,
except those that point to under the output base, such as the convenience
symlinks that are created in the root directory of the workspace.
</p>
<p>
In addition, Bazel does not follow symlinks when evaluating recursive target
patterns in any directory that contains a file named as follows:
<pre>
DONT_FOLLOW_SYMLINKS_WHEN_TRAVERSING_THIS_DIRECTORY_VIA_A_RECURSIVE_TARGET_PATTERN
</pre>
</p>
<p>
Target patterns may be preceded by a single dash ('<code>-</code>'), in which
case Bazel subtracts them from the set of targets accumulated by preceding
patterns. Note that this means <em>order matters</em>. In order to pass negative
target patterns, you need to use '--' as an argument to prevent Bazel from
interpreting it as an option, e.g.:
<pre>
bazel build -- foo/... -foo/contrib/...
</pre>
Note that Bazel may still build targets matched by a negative target pattern due
to dependencies, and may also load the corresponding BUILD files, even if the
targets are never built.
</p>
|
