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
|
Go rules
--------
The files here demonstrate how to use the rules for Go supplied under
`//tools/build_rules:go_rules.bzl`. The rules should be considered
experimental. They support:
* libraries
* binaries
* tests
They currently do not support:
* coverage
* race detector
* multiple target configurations
* //+build tags
* C/C++ interoperation (cgo, swig etc.)
Testing
-------
Setup a symlink to the Go installation you wish to use,
ln -s /usr/lib/golang/ tools/go/go_root
or
ln -s $(go env GOROOT) tools/go/go_root
To build something, run
bazel build examples/go/...
To run a test, run
bazel test --test_arg=--test.v examples/go/lib1:lib1_test
Writing BUILD rules
-------------------
In the bazel model of compiling Go, each directory can hold multiple
packages, rather than just one in the standard "go" tool. Suppose you
have
dir/f.go:
package p
func F() {}
then in the BUILD file could say
go_library(
name = "q",
srcs = ["f.go"])
and you import it with its Bazel name,
import "dir/p/q"
this add the declared package name as namespace, i.e., it is
equivalent to
import p "dir/p/q"
so you use it as follows
import "dir/p/q"
main() {
p.F()
}
Writing tests
-------------
For tests, you should create a separate target,
go_test(
name = "q_test",
srcs = [ "f_test.go" ],
deps = [ ":q" ])
if the test code is in the same package as the library under test
(e.g., because you are testing private parts of the library), you should
use the `library` attribute,
go_test(
name = "q_test",
srcs = [ "f_test.go" ],
library = ":q" )
This causes the test and the library under test to be compiled
together.
FAQ
---
# Why does this not follow the external Go conventions?
These rules were inspired on Google's internal Go rules, which work
like this. For Bazel, these make more sense, because directories in
Bazel do not correspond to single targets.
# Do I have to specify dependencies twice?
Yes, once in the BUILD file, once in the source file. Bazel does not
examine file contents, so it cannot infer the dependencies. It is
possible to generate the BUILD file from the Go sources through a
separate program, though.
Disclaimer
----------
These rules are not supported by Google's Go team.
|
