forked from bazelbuild/bazel
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathbuild-ref.html
1194 lines (1051 loc) · 44.1 KB
/
build-ref.html
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
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
---
layout: documentation
title: BUILD files
---
<h1>Bazel: Build Files and Terminology</h1>
<p>
This document provides an overview of the source tree layout and the
terminology used in Bazel.
</p>
<h2>Table of Contents</h2>
<ul>
<li><a href="#intro">Introduction</a></li>
<li><a href="#packages_targets">Workspace, Packages and Targets</a>
<ul>
<li><a href="#workspace">Workspace</a></li>
<li><a href="#packages">Packages</a></li>
<li><a href="#targets">Targets</a></li>
<li><a href="#labels">Labels</a></li>
<li><a href="#lexi">Lexical Specifications of a Label</a></li>
<li><a href="#rules">Rules</a></li>
</ul>
</li>
<li><a href="#BUILD_files">BUILD Files</a>
<ul>
<li><a href="#core_build_language">The Core Build Language</a></li>
<li><a href="#declaring_build_rules">Declaring Build Rules</a></li>
</ul>
</li>
<li><a href="#funcs">Types of Build Rules</a></li>
<li><a href="#dependencies">Dependencies</a>
<ul>
<li><a href="#actual_and_declared_dependencies">Actual and Declared Dependencies</a></li>
<li><a href="#types_of_dependencies">Types of Dependencies</a></li>
<li><a href="#label_directory">Using Labels to Reference Directories</a></li>
</ul>
</li>
</ul>
<h2 id="intro">Introduction</h2>
<p>Bazel builds software from source code organized in a directory called
a workspace. Source files in the workspace are organized in a nested
hierarchy of packages, where each package is a directory that contains a set
of related source files and one BUILD file. The BUILD file specifies what
software outputs can be built from the source.
</p>
<h2 id="packages_targets">Workspace, Packages and Targets</h2>
<h3 id="workspace">Workspace</h3>
<p>A <em>workspace</em> is a directory on your filesystem that contains the
source files for the software you want to build, as well as symbolic links
to directories that contain the build outputs. Each workspace directory has
a text file named <code>WORKSPACE</code> which may be empty, or may contain
references to <a href="/docs/external.html">external dependencies</a>
required to build the outputs. See also the <a
href="/docs/be/workspace.html">Workspace Rules</a> section in the Build
Encyclopedia.
</p>
<h3 id="packages">Packages</h3>
<p>
The primary unit of code organization in a workspace is
the <i>package</i>. A package is collection of related files and a
specification of the dependencies among them.
</p>
<p>
A package is defined as a directory containing a file
named <code>BUILD</code>, residing beneath the top-level directory in the
workspace. A package includes all files in its directory, plus all
subdirectories beneath it, except those which themselves contain a BUILD
file.
</p>
<p>
For example, in the following directory tree
there are two packages, <code>my/app</code>,
and the subpackage <code>my/app/tests</code>.
Note that <code>my/app/data</code> is not a package, but a directory
belonging to package <code>my/app</code>.
</p>
<pre>
src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc
</pre>
<h3 id="targets">Targets</h3>
<p>
A package is a container. The elements of a package are called
<i>targets</i>. Most targets are one of two principal kinds, <i>files</i>
and <i>rules</i>. Additionally, there is another kind of target,
<a href="be/functions.html#package_group">package groups</a>,
but they are far less numerous.
</p>
<div style='margin:auto; text-align: center'>
<svg width="582pt" height="188pt"
viewBox="0.00 0.00 581.89 188.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 184)">
<title>G1</title>
<polygon fill="white" stroke="transparent" points="-4,4 -4,-184 577.888,-184 577.888,4 -4,4"/>
<!-- Target -->
<g id="node1" class="node">
<title>Target</title>
<ellipse fill="none" stroke="black" cx="376.795" cy="-162" rx="40.0939" ry="18"/>
<text text-anchor="middle" x="376.795" y="-158.3" font-family="arial" font-size="14.00">Target</text>
</g>
<!-- Rule -->
<g id="node2" class="node">
<title>Rule</title>
<ellipse fill="none" stroke="black" cx="241.795" cy="-90" rx="30.5947" ry="18"/>
<text text-anchor="middle" x="241.795" y="-86.3" font-family="arial" font-size="14.00">Rule</text>
</g>
<!-- Target->Rule -->
<g id="edge1" class="edge">
<title>Target->Rule</title>
<path fill="none" stroke="black" d="M351.402,-147.834C329.151,-136.296 296.735,-119.487 272.926,-107.142"/>
<polygon fill="black" stroke="black" points="274.432,-103.98 263.943,-102.484 271.21,-110.195 274.432,-103.98"/>
</g>
<!-- File -->
<g id="node6" class="node">
<title>File</title>
<ellipse fill="none" stroke="black" cx="376.795" cy="-90" rx="30.5947" ry="18"/>
<text text-anchor="middle" x="376.795" y="-86.3" font-family="arial" font-size="14.00">File</text>
</g>
<!-- Target->File -->
<g id="edge5" class="edge">
<title>Target->File</title>
<path fill="none" stroke="black" d="M376.795,-143.697C376.795,-135.983 376.795,-126.712 376.795,-118.112"/>
<polygon fill="black" stroke="black" points="380.295,-118.104 376.795,-108.104 373.295,-118.104 380.295,-118.104"/>
</g>
<!-- Package group -->
<g id="node9" class="node">
<title>Package group</title>
<ellipse fill="none" stroke="black" cx="499.795" cy="-90" rx="74.187" ry="18"/>
<text text-anchor="middle" x="499.795" y="-86.3" font-family="arial" font-size="14.00">Package group</text>
</g>
<!-- Target->Package group -->
<g id="edge8" class="edge">
<title>Target->Package group</title>
<path fill="none" stroke="black" d="M400.802,-147.337C418.506,-137.262 442.911,-123.373 463.059,-111.906"/>
<polygon fill="black" stroke="black" points="465.018,-114.819 471.978,-106.831 461.555,-108.735 465.018,-114.819"/>
</g>
<!-- cc_library -->
<g id="node3" class="node">
<title>cc_library</title>
<ellipse fill="none" stroke="black" cx="59.7947" cy="-18" rx="59.5901" ry="18"/>
<text text-anchor="middle" x="59.7947" y="-14.3" font-family="arial" font-size="14.00">cc_library</text>
</g>
<!-- Rule->cc_library -->
<g id="edge2" class="edge">
<title>Rule->cc_library</title>
<path fill="none" stroke="black" d="M216.87,-79.4136C188.038,-68.3243 140.006,-49.8505 104.633,-36.2453"/>
<polygon fill="black" stroke="black" points="105.607,-32.8704 95.0176,-32.5473 103.095,-39.4038 105.607,-32.8704"/>
</g>
<!-- java_test -->
<g id="node4" class="node">
<title>java_test</title>
<ellipse fill="none" stroke="black" cx="191.795" cy="-18" rx="54.6905" ry="18"/>
<text text-anchor="middle" x="191.795" y="-14.3" font-family="arial" font-size="14.00">java_test</text>
</g>
<!-- Rule->java_test -->
<g id="edge3" class="edge">
<title>Rule->java_test</title>
<path fill="none" stroke="black" d="M230.449,-73.1159C224.298,-64.5051 216.557,-53.6674 209.621,-43.9567"/>
<polygon fill="black" stroke="black" points="212.453,-41.9004 203.793,-35.7973 206.757,-45.9691 212.453,-41.9004"/>
</g>
<!-- ... -->
<g id="node5" class="node">
<title>...</title>
<ellipse fill="none" stroke="black" cx="291.795" cy="-18" rx="27" ry="18"/>
<text text-anchor="middle" x="291.795" y="-14.3" font-family="arial" font-size="14.00">...</text>
</g>
<!-- Rule->... -->
<g id="edge4" class="edge">
<title>Rule->...</title>
<path fill="none" stroke="black" d="M253.14,-73.1159C259.469,-64.2555 267.482,-53.0373 274.57,-43.1152"/>
<polygon fill="black" stroke="black" points="277.529,-44.9929 280.494,-34.8212 271.833,-40.9242 277.529,-44.9929"/>
</g>
<!-- Source -->
<g id="node7" class="node">
<title>Source</title>
<ellipse fill="none" stroke="black" cx="376.795" cy="-18" rx="40.0939" ry="18"/>
<text text-anchor="middle" x="376.795" y="-14.3" font-family="arial" font-size="14.00">Source</text>
</g>
<!-- File->Source -->
<g id="edge6" class="edge">
<title>File->Source</title>
<path fill="none" stroke="black" d="M376.795,-71.6966C376.795,-63.9827 376.795,-54.7125 376.795,-46.1124"/>
<polygon fill="black" stroke="black" points="380.295,-46.1043 376.795,-36.1043 373.295,-46.1044 380.295,-46.1043"/>
</g>
<!-- Generated -->
<g id="node8" class="node">
<title>Generated</title>
<ellipse fill="none" stroke="black" cx="489.795" cy="-18" rx="54.6905" ry="18"/>
<text text-anchor="middle" x="489.795" y="-14.3" font-family="arial" font-size="14.00">Generated</text>
</g>
<!-- File->Generated -->
<g id="edge7" class="edge">
<title>File->Generated</title>
<path fill="none" stroke="black" d="M396.997,-76.4854C413.512,-66.2547 437.203,-51.579 456.513,-39.6169"/>
<polygon fill="black" stroke="black" points="458.378,-42.579 465.036,-34.3375 454.691,-36.6283 458.378,-42.579"/>
</g>
</g>
</svg>
<p><i>Hierarchy of targets.</i></p>
</div>
<p>
Files are further divided into two kinds.
<i>Source files</i> are usually written by the efforts of people,
and checked in to the repository.
<i>Generated files</i>, sometimes called derived files,
are not checked in, but are generated by the build tool from source
files according to specific rules.
</p>
<p>
The second kind of target is the <i>rule</i>. A rule specifies the
relationship between a set of input and a set of output files,
including the necessary steps to derive the outputs from the inputs.
The outputs of a rule are always generated files. The inputs to a
rule may be source files, but they may be generated files also;
consequently, outputs of one rule may be the inputs to another,
allowing long chains of rules to be constructed.
</p>
<p>
Whether the input to a rule is a source file or a generated file is
in most cases immaterial; what matters is only the contents of that
file. This fact makes it easy to replace a complex source file with
a generated file produced by a rule, such as happens when the burden
of manually maintaining a highly structured file becomes too
tiresome, and someone writes a program to derive it. No change is
required to the consumers of that file. Conversely, a generated
file may easily be replaced by a source file with only local
changes.
</p>
<p>
The inputs to a rule may also include <i>other rules</i>. The
precise meaning of such relationships is often quite complex and
language- or rule-dependent, but intuitively it is simple: a C++
library rule A might have another C++ library rule B for an input.
The effect of this dependency is that the B's header files are
available to A during compilation, B's symbols are available to A
during linking, and B's runtime data is available to A during
execution.
</p>
<p>
An invariant of all rules is that the files generated by a rule
always belong to the same package as the rule itself; it is not
possible to generate files into another package. It is not uncommon
for a rule's inputs to come from another package, though.
</p>
<p>
Package groups are sets of packages whose purpose is to limit accessibility
of certain rules. Package groups are defined by the
<code>package_group</code> function. They have two properties: the list of
packages they contain and their name. The only allowed ways to refer to them
are from the <code>visibility</code> attribute of rules or from the
<code>default_visibility</code> attribute of the <code>package</code>
function; they do not generate or consume files. For more information, refer
to the appropriate section of the <a
href='be/functions.html#package_group'>Build Encyclopedia</a>.
</p>
<h3 id="labels">Labels</h3>
<p>
All targets belong to exactly one package. The name of a target is
called its <em>label</em>, and a typical label in canonical form
looks like this:
</p>
<pre>
//my/app/main:app_binary
</pre>
<p>
Each label has two parts, a package name (<code>my/app/main</code>)
and a target name (<code>app_binary</code>). Every label uniquely
identifies a target. Labels sometimes appear in other forms; when
the colon is omitted, the target name is assumed to be the same as
the last component of the package name, so these two labels are
equivalent:
</p>
<pre>
//my/app
//my/app:app
</pre>
<p>
Short-form labels such as <code>//my/app</code> are not to
be confused with package names. Labels start with <code>//</code>,
but package names never do, thus <code>my/app</code> is the
package containing <code>//my/app</code>.
(A common misconception is that <code>//my/app</code> refers
to a package, or to <em>all</em> the targets in a package; neither
is true.)
</p>
<p>
Within a BUILD file, the package-name part of label may be omitted,
and optionally the colon too. So within the BUILD file for package
<code>my/app</code> (i.e. <code>//my/app:BUILD</code>),
the following "relative" labels are all equivalent:
</p>
<pre>
//my/app:app
//my/app
:app
app
</pre>
<p>
(It is a matter of convention that the colon is omitted for files,
but retained for rules, but it is not otherwise significant.)
</p>
<p>
Similarly, within a BUILD file, files belonging to the package may
be referenced by their unadorned name relative to the package
directory:
</p>
<pre>
generate.cc
testdata/input.txt
</pre>
<p>
But from other packages, or from the command-line, these file
targets must always be referred to by their complete label, e.g.
<code>//my/app:generate.cc</code>.
</p>
<p>
Relative labels cannot be used to refer to targets in other
packages; the complete package name must always be specified in this
case. For example, if the source tree contains both the package
<code>my/app</code> and the package
<code>my/app/testdata</code> (i.e., each of these two
packages has its own BUILD file). The latter package contains a
file named <code>testdepot.zip</code>. Here are two ways (one
wrong, one correct) to refer to this file within
<code>//my/app:BUILD</code>:
</p>
<pre>
<span class="discouraged">testdata/testdepot.zip</span> # Wrong: testdata is a different package.
//my/app/testdata:testdepot.zip # Right.
</pre>
<p>
If, by mistake, you refer to <code>testdepot.zip</code> by the wrong
label, such as <code>//my/app:testdata/testdepot.zip</code>
or <code>//my:app/testdata/testdepot.zip</code>, you will get an
error from the build tool saying that the label "crosses a package
boundary". You should correct the label by putting the colon after
the directory containing the innermost enclosing BUILD file, i.e.,
<code>//my/app/testdata:testdepot.zip</code>.
</p>
<h3 id="lexi">Lexical specification of a label</h3>
<p>
The syntax of labels is intentionally strict, so as to
forbid metacharacters that have special meaning to the shell. This
helps to avoid inadvertent quoting problems, and makes it easier to
construct tools and scripts that manipulate labels, such as the
<a href="query.html">Bazel Query Language</a>.
All of the following are forbidden in labels: any sort of white
space, braces, brackets, or parentheses; wildcards such
as <code>*</code>; shell metacharacters such
as <code>></code>, <code>&</code> and <code>|</code>; etc.
This list is not comprehensive; the precise details are below.
</p>
<h4 id="name">Target names, <code>//...:<b>target-name</b></code></h4>
<p><code>target-name</code> is the name of the target within the package.
The name of a rule is the value of the <code>name</code>
parameter in the rule's declaration in a BUILD file; the name
of a file is its pathname relative to the directory containing
the BUILD file.
Target names must be composed entirely of
characters drawn from the set <code>a</code>–<code>z</code>,
<code>A</code>–<code>Z</code>, <code>0</code>–<code>9</code>,
and the punctuation symbols <code>_/.+-=,@~</code>.
Do not use <code>..</code> to refer to files in other packages; use
<code>//<var>packagename</var>:<var>filename</var></code> instead.
Filenames must be relative pathnames in normal form, which means
they must neither start nor end with a slash
(e.g. <code>/foo</code> and <code>foo/</code> are forbidden) nor
contain multiple consecutive slashes as path separators
(e.g. <code>foo//bar</code>). Similarly, up-level references
(<code>..</code>) and current-directory references
(<code>./</code>) are forbidden. The sole exception to this
rule is that a target name may consist of exactly
'<code>.</code>'.
</p>
<p>While it is common to use <code>/</code> in the name of a file
target, we recommend that you avoid the use of <code>/</code> in the
names of rules. Especially when the shorthand form of a label is
used, it may confuse the reader. The
label <code>//foo/bar/wiz</code> is always a shorthand
for <code>//foo/bar/wiz:wiz</code>, even if there is no such package
<code>foo/bar/wiz</code>; it never refers to <code>//foo:bar/wiz</code>,
even if that target exists.</p>
<p>However, there are some situations where use of a slash is
convenient, or sometimes even necessary. For example, the name of
certain rules must match their principal source file, which may
reside in a subdirectory of the package.</p>
<h4>Package names, <code>//<b>package-name</b>:...</code></h4>
<p>
The name of a package is the name of the directory containing its
BUILD file, relative to the top-level directory of the source tree.
For example: <code>my/app</code>.
Package names must be composed entirely of characters drawn from
the set <code>A</code>-<code>Z</code>, <code>a</code>–<code>z</code>,
<code>0</code>–<code>9</code>, '<code>/</code>', '<code>-</code>',
'<code>.</code>', and '<code>_</code>', and cannot start with
a slash.
<p>
For a language with a directory structure that is significant
to its module system (e.g. Java), it is important to choose directory names
that are valid identifiers in the language.
</p>
<p>
Although Bazel allows a package at the build root (e.g. <code>//:foo</code>), this
is not advised and projects should attempt to use more descriptively named
packages.
</p>
<p>
Package names may not contain the substring <code>//</code>, nor
end with a slash.
</p>
<h3 id="rules">Rules</h3>
<p>
A rule specifies the relationship between inputs and outputs, and the
steps to build the outputs. Rules can be of one of many different
kinds or <i>classes</i>, which produce compiled
executables and libraries, test executables and other supported
outputs as described in the
<a href="be/overview.html">Build Encyclopedia</a>.
</p>
<p>
Every rule has a name, specified by the <code>name</code> attribute,
of type string. The name must be a syntactically valid target name,
as specified <a href='#name'>above</a>. In some cases, the name is
somewhat arbitrary, and more interesting are the names of the files
generated by the rule; this is true of genrules. In other
cases, the name is significant: for <code>*_binary</code>
and <code>*_test</code> rules, for example, the rule name determines
the name of the executable produced by the build.
</p>
<p>
Every rule has a set of <i>attributes</i>; the applicable attributes
for a given rule, and the significance and semantics of each
attribute are a function of the rule's class; see
the <a href='be/overview.html'>Build
Encyclopedia</a> for the full list of supported rules and their
corresponding attributes. Each attribute has a name and a
type. The full set of types that an attribute can have is: integer,
label, list of labels, string, list of strings, output label,
list of output labels. Not all attributes need to be specified in
every rule. Attributes thus form a dictionary from keys (names) to
optional, typed values.
</p>
<p>
The <code>srcs</code> attribute present in many rules has type "list
of label"; its value, if present, is a list of labels, each being
the name of a target that is an input to this rule.
</p>
<p>
The <code>outs</code> attribute present in many rules has type "list
of output labels"; this is similar to the type of
the <code>srcs</code> attribute, but differs in two significant
ways. Firstly, due to the invariant that the outputs of a rule
belong to the same package as the rule itself, output labels cannot
include a package component; they must be in one of the "relative"
forms shown above. Secondly, the relationship implied by an
(ordinary) label attribute is inverse to that implied by an output
label: a rule <i>depends on</i> its <code>srcs</code>, whereas a rule <i>is
depended on by</i> its <code>outs</code>. The two types of label attributes
thus assign direction to the edges between targets, giving rise to a
dependency graph.
</p>
<p>
The figure below represents an example fragment of the build
dependency graph, and illustrates: files (circles) and rules
(boxes); dependencies from generated files to rules; dependencies
from rules to files, and from rules to other rules. Conventionally,
dependency arrows are represented as pointing from a target towards
its prerequisites.
</p>
<div style="margin:auto; text-align:center">
<svg width="157pt" height="246pt"
viewBox="0.00 0.00 156.50 246.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 242)">
<title>G1</title>
<polygon fill="white" stroke="transparent" points="-4,4 -4,-242 152.5,-242 152.5,4 -4,4"/>
<!-- r1 -->
<g id="node1" class="node">
<title>r1</title>
<polygon fill="none" stroke="black" points="88.5,-173 34.5,-173 34.5,-137 88.5,-137 88.5,-173"/>
<text text-anchor="middle" x="61.5" y="-152.5" font-family="arial" font-size="10.00" fill="#006000">rule</text>
</g>
<!-- s1 -->
<g id="node3" class="node">
<title>s1</title>
<ellipse fill="none" stroke="black" cx="14.5" cy="-223.5" rx="14.5" ry="14.5"/>
<text text-anchor="middle" x="14.5" y="-221" font-family="arial" font-size="10.00" fill="#006000">in</text>
</g>
<!-- r1->s1 -->
<g id="edge1" class="edge">
<title>r1->s1</title>
<path fill="none" stroke="black" d="M49.3963,-173.125C42.9655,-182.224 35.0324,-193.449 28.3559,-202.895"/>
<polygon fill="black" stroke="black" points="25.3432,-201.094 22.4297,-211.28 31.0596,-205.134 25.3432,-201.094"/>
</g>
<!-- s2 -->
<g id="node4" class="node">
<title>s2</title>
<ellipse fill="none" stroke="black" cx="61.5" cy="-223.5" rx="14.5" ry="14.5"/>
<text text-anchor="middle" x="61.5" y="-221" font-family="arial" font-size="10.00" fill="#006000">in</text>
</g>
<!-- r1->s2 -->
<g id="edge2" class="edge">
<title>r1->s2</title>
<path fill="none" stroke="black" d="M61.5,-173.125C61.5,-180.918 61.5,-190.27 61.5,-198.729"/>
<polygon fill="black" stroke="black" points="58.0001,-198.782 61.5,-208.782 65.0001,-198.782 58.0001,-198.782"/>
</g>
<!-- s3 -->
<g id="node5" class="node">
<title>s3</title>
<ellipse fill="none" stroke="black" cx="108.5" cy="-223.5" rx="14.5" ry="14.5"/>
<text text-anchor="middle" x="108.5" y="-221" font-family="arial" font-size="10.00" fill="#006000">in</text>
</g>
<!-- r1->s3 -->
<g id="edge3" class="edge">
<title>r1->s3</title>
<path fill="none" stroke="black" d="M73.6037,-173.125C80.0345,-182.224 87.9676,-193.449 94.6441,-202.895"/>
<polygon fill="black" stroke="black" points="91.9404,-205.134 100.57,-211.28 97.6568,-201.094 91.9404,-205.134"/>
</g>
<!-- r2 -->
<g id="node2" class="node">
<title>r2</title>
<polygon fill="none" stroke="black" points="148.5,-101 94.5,-101 94.5,-65 148.5,-65 148.5,-101"/>
<text text-anchor="middle" x="121.5" y="-80.5" font-family="arial" font-size="10.00" fill="#006000">rule</text>
</g>
<!-- r2->r1 -->
<g id="edge5" class="edge">
<title>r2->r1</title>
<path fill="none" stroke="black" d="M106.669,-101.303C99.4753,-109.695 90.7033,-119.93 82.8097,-129.139"/>
<polygon fill="black" stroke="black" points="80.0114,-127.025 76.1609,-136.896 85.3262,-131.581 80.0114,-127.025"/>
</g>
<!-- s4 -->
<g id="node6" class="node">
<title>s4</title>
<ellipse fill="none" stroke="black" cx="121.5" cy="-155" rx="14.5" ry="14.5"/>
<text text-anchor="middle" x="121.5" y="-152.5" font-family="arial" font-size="10.00" fill="#006000">in</text>
</g>
<!-- r2->s4 -->
<g id="edge4" class="edge">
<title>r2->s4</title>
<path fill="none" stroke="black" d="M121.5,-101.303C121.5,-110.01 121.5,-120.7 121.5,-130.171"/>
<polygon fill="black" stroke="black" points="118,-130.175 121.5,-140.175 125,-130.176 118,-130.175"/>
</g>
<!-- o1 -->
<g id="node7" class="node">
<title>o1</title>
<ellipse fill="none" stroke="black" cx="61.5" cy="-83" rx="14.5" ry="14.5"/>
<text text-anchor="middle" x="61.5" y="-80.5" font-family="arial" font-size="10.00" fill="#006000">out</text>
</g>
<!-- o1->r1 -->
<g id="edge6" class="edge">
<title>o1->r1</title>
<path fill="none" stroke="black" d="M61.5,-97.8297C61.5,-106.081 61.5,-116.847 61.5,-126.744"/>
<polygon fill="black" stroke="black" points="58.0001,-126.981 61.5,-136.981 65.0001,-126.981 58.0001,-126.981"/>
</g>
<!-- o2 -->
<g id="node8" class="node">
<title>o2</title>
<ellipse fill="none" stroke="black" cx="121.5" cy="-14.5" rx="14.5" ry="14.5"/>
<text text-anchor="middle" x="121.5" y="-12" font-family="arial" font-size="10.00" fill="#006000">out</text>
</g>
<!-- o2->r2 -->
<g id="edge7" class="edge">
<title>o2->r2</title>
<path fill="none" stroke="black" d="M121.5,-29.2788C121.5,-36.6355 121.5,-45.9556 121.5,-54.7067"/>
<polygon fill="black" stroke="black" points="118,-54.9286 121.5,-64.9286 125,-54.9286 118,-54.9286"/>
</g>
</g>
</svg>
<p><i>Source files, rules, and generated files.</i></p>
</div>
<p>
This directed acyclic graph over targets is called the
"target graph" or "build dependency graph", and is the domain over
which the
<a href="query.html">Bazel Query tool</a></li>
operates.
</p>
<h2 id="BUILD_files">BUILD Files</h2>
<p>
The previous section described packages, targets and labels, and the
build dependency graph abstractly. In this section, we'll look at
the concrete syntax used to define a package.
</p>
<p>
By definition, every package contains a BUILD file, which is a short
program written in the Build Language. Most BUILD files
appear to be little more than a series of declarations of build
rules; indeed, the declarative style is strongly encouraged when
writing BUILD files.
</p>
<p>
However, the build language is in fact an imperative language, and
BUILD files are interpreted as a sequential list of statements.
Build rule functions, such as <code>cc_library</code>, are procedures whose
side-effect is to create an abstract build rule inside the build tool.
</p>
<p>
The concrete syntax of BUILD files is a subset of Python.
Originally, the syntax <i>was</i> that of Python, but experience
showed that users rarely used more than a tiny subset of Python's
features, and when they did, it often resulted in complex and
fragile BUILD files. In many cases, the use of such features was
unnecessary, and the same result could be achieved by using an
external program, e.g. via a <code>genrule</code> build rule.
</p>
<p>
Crucially, programs in the build language are unable to perform
arbitrary I/O (though many users try!). This invariant makes the
interpretation of BUILD files hermetic, i.e. dependent only on a
known set of inputs, which is essential for ensuring that builds are
reproducible.
</p>
<h3 id="core_build_language">The Core Build Language</h3>
<p>
<b>Lexemes</b>: the lexical syntax of the core language is a strict
subset of Python 2.6, and we refer the reader to the <a
href='http://docs.python.org/reference/lexical_analysis.html'>Python
specification</a> for details.
Lexical features of Python that are not
supported include: floating-point literals, hexadecimal and Unicode
escapes within string literals.
</p>
<p>
BUILD files should be written using only ASCII characters,
although technically they are interpreted using the Latin-1
character set. The use
of <a href='http://www.python.org/dev/peps/pep-0263/'><code>coding:</code></a>
declarations is forbidden.
</p>
<p>
<b>Grammar</b>: the grammar of the core language is shown below,
using EBNF notation. Ambiguity is resolved using precedence, which
is defined as for Python.
</p>
<pre>
file_input ::= (simple_stmt? '\n')*
simple_stmt ::= small_stmt (';' small_stmt)* ';'?
small_stmt ::= expr
| assign_stmt
assign_stmt ::= IDENTIFIER '=' expr
expr ::= INTEGER
| STRING+
| IDENTIFIER
| IDENTIFIER '(' arg_list? ')'
| expr '.' IDENTIFIER
| expr '.' IDENTIFIER '(' arg_list? ')'
| '[' expr_list? ']'
| '[' expr ('for' IDENTIFIER 'in' expr)+ ']'
| '(' expr_list? ')'
| '{' dict_entry_list? '}'
| '{' dict_entry ('for' IDENTIFIER 'in' expr)+ '}'
| expr '+' expr
| expr '-' expr
| expr '%' expr
| '-' expr
| expr '[' expr? ':' expr? ']'
| expr '[' expr ']'
expr_list ::= (expr ',')* expr ','?
dict_entry_list ::= (dict_entry ',')* dict_entry ','?
dict_entry ::= expr ':' expr
arg_list ::= (arg ',')* arg ','?
arg ::= IDENTIFIER '=' expr
| expr
</pre>
<p>
For each expression of the core language, the semantics are
identical to the corresponding Python semantics, except in the
following cases:
</p>
<ul>
<li>certain overloads of the binary <code>%</code> operator are not
supported. Only the <code>int % int</code> and <code>str %
tuple</code> forms are supported. Only the <code>%s</code>
and <code>%d</code> format specifiers may be
used; <code>%(var)s</code> is illegal.</li>
</ul>
<p>
Many Python features are missing: control-flow constructs (loops,
conditionals, exceptions), basic datatypes (floating-point numbers, big
integers), <code>import</code> and the module system, support for
definition of classes, some Python's built-in functions. Function
definitions and <code>for</code> statements are allowed only in
extension files (<code>.bzl</code>).
Available functions are documented in
the <a href="skylark/lib/globals.html">library section</a>.
<h3 id="declaring_build_rules">Declaring build rules</h3>
<p>
The build language is an imperative language, so in general, order
does matter: variables must be defined before they are used, for
example. However, most BUILD files consist only of declarations of
build rules, and the relative order of these statements is
immaterial; all that matters is <em>which</em> rules were declared,
and with what values, by the time package evaluation completes.
So, in simple BUILD files, rule declarations can be re-ordered
freely without changing the behavior.
</p>
<p>
BUILD file authors are encouraged to use comments liberally to
document the role of each build target, whether it is intended for
public use, and anything else that would help users and future
maintainers, including a <code># Description:</code> comment at the
top, explaining the role of the package.
</p>
<p>
The Python comment syntax of <code>#...</code> is supported.
Triple-quoted string literals may span multiple lines, and can be used
for multi-line comments.
</p>
<h2 id="funcs">Types of build rule</h2>
<p>
The majority of build rules come in families, grouped together by
language. For
example, <code>cc_binary</code>, <code>cc_library</code>
and <code>cc_test</code> are the build rules for C++ binaries,
libraries, and tests, respectively. Other languages use the same
naming scheme, with a different prefix, e.g. <code>java_*</code> for
Java. These functions are all documented in the
<a href="be/overview.html">Build Encyclopedia</a>.
</p>
<ul>
<li><p><code>*_binary</code>
rules build executable programs in a given language. After a
build, the executable will reside in the build tool's binary
output tree at the corresponding name for the rule's label,
so <code>//my:program</code> would appear at
(e.g.) <code>$(BINDIR)/my/program</code>. </p>
<p>Such rules also create a runfiles directory
containing all the files mentioned in a <code>data</code>
attribute belonging to the rule, or any rule in its transitive
closure of dependencies; this set of files is gathered together in
one place for ease of deployment to production.</p>
</li>
<li><p><code>*_test</code>
rules are a specialization of a <code>*_binary</code> rule, used for automated
testing. Tests are simply programs that return zero on success.
</p>
<p>
Like binaries, tests also have runfiles trees, and the files
beneath it are the only files that a test may legitimately open
at runtime. For example, a program <code>cc_test(name='x',
data=['//foo:bar'])</code> may open and
read <code>$TEST_SRCDIR/workspace/foo/bar</code> during execution.
(Each programming language has its own utility function for
accessing the value of <code>$TEST_SRCDIR</code>, but they are all
equivalent to using the environment variable directly.)
Failure to observe the rule will cause the test to fail when it is
executed on a remote testing host.
</p>
</li>
<li><code>*_library</code>
rules specify separately-compiled modules in the given
programming language. Libraries can depend on other libraries,
and binaries and tests can depend on libraries, with the expected
separate-compilation behavior.
</li>
</ul>
<h2 id="dependencies">Dependencies</h2>
<p>
A target <code>A</code> <i>depends upon</i> a target
<code>B</code> if <code>B</code> is needed by <code>A</code> at
build or execution time. The <i>depends upon</i> relation induces a
directed acyclic graph (DAG) over targets, and we call this a
<em>dependency graph</em>.
A target's <em>direct</em> dependencies are those other targets
reachable by a path of length 1 in the dependency graph. A target's
<em>transitive</em> dependencies are those targets upon which it
depends via a path of any length through the graph.
</p>
<p>
In fact, in the context of builds, there are two dependency graphs,
the graph of <em>actual dependencies</em> and the graph of
<em>declared dependencies</em>. Most of the time, the two graphs
are so similar that this distinction need not be made, but it is
useful for the discussion below.
</p>
<h3 id="actual_and_declared_dependencies">Actual and declared dependencies</h3>
<p>
A target <code>X</code> is <i>actually dependent</i> on target
<code>Y</code> iff <code>Y</code> must be present, built and
up-to-date in order for <code>X</code> to be built correctly.
"Built" could mean generated, processed, compiled, linked,
archived, compressed, executed, or any of the other kinds of tasks
that routinely occur during a build.
</p>
<p>
A target <code>X</code> has a <i>declared dependency</i> on target
<code>Y</code> iff there is a dependency edge from <code>X</code> to
<code>Y</code> in the package of <code>X</code>.
</p>
<p>
For correct builds, the graph of actual dependencies <i>A</i> must
be a subgraph of the graph of declared dependencies <i>D</i>. That
is, every pair of directly-connected nodes <code>x --> y</code>
in <i>A</i> must also be directly connected in <i>D</i>. We say
<i>D</i> is an <em>overapproximation</em> of <i>A</i>.
</p>
<p>
It is important that it not be too much of an overapproximation,
though, since redundant declared dependencies can make builds slower and
binaries larger.
</p>
<p>
What this means for BUILD file writers is that every rule must
explicitly declare all of its actual direct dependencies to the
build system, and no more.
Failure to observe this principle causes undefined behavior: the
build may fail, but worse, the build may depend on some prior
operations, or upon which transitive declared dependencies the target
happens to have. The build tool attempts aggressively to check for
missing dependencies and report errors, but it is not possible for
this checking to be complete in all cases.
</p>
<p>
You need not (and should not) attempt to list everything indirectly imported,
even if it is "needed" by A at execution time.
</p>
<p>
During a build of target <code>X</code>, the build tool inspects the
entire transitive closure of dependencies of <code>X</code> to ensure that
any changes in those targets are reflected in the final result,
rebuilding intermediates as needed.
</p>
<p>
The transitive nature of dependencies leads to a common mistake.
Through careless programming, code in one file may use code provided
by an <em>indirect</em> dependency, i.e. a transitive but not direct
edge in the declared dependency graph. Indirect dependencies do not
appear in the BUILD file. Since the rule doesn't
directly depend on the provider, there is no way to track changes,
as shown in the following example timeline:
</p>
<div class="greenbox">
<p><b>1. At first, everything works</b></p>
<p>The code in package <code>a</code> uses code in package <code>b</code>.
The code in package <code>b</code> uses code in package <code>c</code>,
and thus <code>a</code> transitively depends on <code>c</code>.</p>
<div style="float:left; width: 49%; margin-top: -20px;">
<p><code>a/BUILD</code></p>
<pre class="code">
<b>rule(
name = "a",
srcs = "a.in",
deps = "//b:b",
)</b>
</pre>
<p><code>a/a.in</code></p>
<pre class="code">
<b>import b;
b.foo();</b>
</pre>
</div>
<div style="float:right; width: 49%; margin-top: -20px; ">
<p><code>b/BUILD</code></p>
<pre class="code">
<b>rule(
name = "b",
srcs = "b.in",
deps = "//c:c",
)</b>
</pre>
<p><code>b/b.in</code></p>
<pre class="code">
<b>import c;
function foo() {
c.bar();
}</b>
</pre>
</div>
<pre style="clear: both;">
Declared dependency graph: a --> b --> c
Actual dependency graph: a --> b --> c
</pre>
The declared dependencies overapproximate the actual dependencies.
All is well.
</div>
<div class="greenbox">
<p><b>2. A latent hazard is introduced.</b></p>
<p>
Someone carelessly adds code to <code>a</code> that creates a direct
actual dependency on <code>c</code>, but forgets to declare it.
</p>
<div style="float:left; width: 49%; margin-top: -20px; ">