Provide Go support in Bazel that feels familiar to existing Go users and existing Go tools.
Users might find benefit from using Bazel for Go in the following scenarios:
go
natively. For example: test iOS app running against a Go backend from a single tool, or Bazel itself, where the BUILD file formatter (buildifier
) is written Go, and Bazel (Java/C++) interact.go
become a problem.The Go rules should not impose restrictions on how non-Go projects should organize their source trees.
go_library
, go_binary
and go_test
rules. These take go files as srcs, and go_library
rules as deps
. Along with the rules, we will have a tool that generates the main.go file based on the sources of a go_test rule.GO_PREFIX
. GO_PREFIX
is set through Bazel's WORKSPACE
mechanism, and may be empty. It is recommended that Go projects use the canonical import name (eg. github.com/name/project
) as GO_PREFIX
in Bazel.//a/b:c
. These are to be imported as GO_PREFIX/a/b/c
. This convention is typically used for depending on generated Go code.go_default_library
. A dependency on //a/b:go_default_library
will be staged by Bazel so it can be imported in a go file as GO_PREFIX/a/b
, rather than GO_PREFIX/a/b/go_default_library
.glaze
, which analyzes the Go source files in a directory, and emits a BUILD file to match. Glaze must be run by hand (or, as an editor hook) when modifying Go code.GO_PREFIX/a/b
for which a/b/
is a directory, it will write a dependency on //a/b:go_default_library
.vendor
directory component, the compiler will be invoked with a corresponding -importmap
option, eg. a dependency on x/y/vendor/domain/p/q:target
will yield -importmap=domain/p/q/target=GO_PREFIX/x/y/vendor/domain/p/q/target
.vendor/
directory, as specified in the Go vendoring decision, it will emit the full target name of the vendored library.Is not fully compatible with the go
tool:
go
still cannot handle generated source code (ie. protocol buffers)src
for go
to work with it (possibly through a symlink)go generate
:go
tooling does not work out of the box if only parts of a go library are generated.//go:generate
lines in the source, but the command line will not run if the generator was built by Bazel too.//go:generate
lines. Since the lines do not declare the sources of the invoked tooling, this will be hard to automatically get right, though.GO_PREFIX
that WORKSPACE
sets is similar to the workspace name (see build encyclopedia), but it should only affect Go. Since Go prefixes are URLs, they contain dots, so using the WORKSPACE
name would break Python imports.go_prefix
support in WORKSPACE
go_default_library
and go_prefix
.BUILD
file formatter, and use it as basis to create glaze
.