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
|
Go rules
--------
The files here demonstrate how to use the supplied rules for Go.
They do 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()
}
FAQ
---
# Why does this not follow the external Go conventions?
These rules were inspired on Google's internal Go rules, which work
like this. They make more sense for Bazel, because directories in
Bazel do not correspond to single rules.
# 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.
|
