These are the core go rules, required for basic operation. The intent is that these rules are sufficient to match the capabilities of the normal go tools.
Contents
Three core rules may be used to build most projects: go_library, go_binary, and go_test.
go_library builds a single package. It has a list of source files
(specified with srcs) and may depend on other packages (with deps).
Each go_library has an importpath, which is the name used to import it
in Go source files.
go_binary also builds a single main package and links it into an
executable. It may embed the content of a go_library using the embed
attribute. Embedded sources are compiled together in the same package.
Binaries can be built for alternative platforms and configurations by setting
goos, goarch, and other attributes.
go_test builds a test executable. Like tests produced by go test, this
consists of three packages: an internal test package compiled together with
the library being tested (specified with embed), an external test package
compiled separately, and a generated test main package.
This builds a Go library from a set of source files that are all part of the same package.
| Name | Type | Default value |
| name | string | mandatory value |
A unique name for the library. For targets generated by Gazelle, this is
typically the last component of the path, or go_default_library,
with the old naming convention |
||
| importpath | string | mandatory value |
The source import path of this library. Other libraries can import this
library using this path. This must either be specified in go_library or
inherited from one of the libraries in embed. |
||
| importmap | string | importpath |
The actual import path of this library. This is mostly only visible to the
compiler and linker, but it may also be seen in stack traces. This must be
unique among packages passed to the linker. It may be set to something
different than importpath to prevent conflicts between multiple packages
with the same path (for example, from different vendor directories). |
||
| srcs | label_list | [] |
The list of Go source files that are compiled to create the package.
Only .go and .s files are permitted, unless the cgo
attribute is set, in which case,
.c .cc .cpp .cxx .h .hh .hpp .hxx .inc .m .mm
files are also permitted. Files may be filtered at build time
using Go build constraints. |
||
| embedsrcs | label_list | [] |
The list of files that may be embedded into the compiled package using
//go:embed directives. All files must be in the same logical directory
or a subdirectory as source files. All source files containing //go:embed
directives must be in the same logical directory. It's okay to mix static and
generated source files and static and generated embeddable files. |
||
| x_defs | string_dict | {} |
| Map of defines to add to the go link command. See Defines and stamping for examples of how to use these. | ||
| deps | label_list | [] |
List of Go libraries this package imports directly.
These may be go_library rules or compatible rules with the GoLibrary provider. |
||
| embed | label_list | [] |
List of Go libraries whose sources should be compiled together with this
package's sources. Labels listed here must name go_library,
go_proto_library, or other compatible targets with the GoLibrary and
GoSource providers. Embedded libraries must have the same importpath as
the embedding library. At most one embedded library may have cgo = True,
and the embedding library may not also have cgo = True. See Embedding
for more information. |
||
| data | label_list | [] |
| List of files needed by this rule at run-time. This may include data files needed or other programs that may be executed. The bazel package may be used to locate run files; they may appear in different places depending on the operating system and environment. See data dependencies for more information on data files. | ||
| gc_goopts | string_list | [] |
| List of flags to add to the Go compilation command when using the gc compiler. Subject to "Make variable" substitution and Bourne shell tokenization. | ||
| cgo | boolean | False |
If True, the package may contain cgo code, and srcs may contain
C, C++, Objective-C, and Objective-C++ files and non-Go assembly files.
When cgo is enabled, these files will be compiled with the C/C++ toolchain
and included in the package. Note that this attribute does not force cgo
to be enabled. Cgo is enabled for non-cross-compiling builds when a C/C++
toolchain is configured. |
||
| cdeps | label_list | [] |
List of other libraries that the c code depends on.
This can be anything that would be allowed in cc_library deps
Only valid if cgo = True. |
||
| copts | string_list | [] |
List of flags to add to the C compilation command.
Subject to "Make variable" substitution and Bourne shell tokenization.
Only valid if cgo = True. |
||
| cxxopts | string_list | [] |
List of flags to add to the C++ compilation command.
Subject to "Make variable" substitution and Bourne shell tokenization.
Only valid if cgo = True. |
||
| cppopts | string_list | [] |
List of flags to add to the C/C++ preprocessor command.
Subject to "Make variable" substitution and Bourne shell tokenization.
Only valid if cgo = True. |
||
| clinkopts | string_list | [] |
List of flags to add to the C link command.
Subject to "Make variable" substitution and Bourne shell tokenization.
Only valid if cgo = True. |
||
go_library(
name = "foo",
srcs = [
"foo.go",
"bar.go",
],
deps = [
"//tools",
"@org_golang_x_utils//stuff",
],
importpath = "github.com/example/project/foo",
visibility = ["//visibility:public"],
)This builds an executable from a set of source files, which must all be
in the main package. You can run the binary with bazel run, or you can
build it with bazel build and run it directly.
| Name | Type | Default value |
| name | string | mandatory value |
A unique name for this rule. This should be named the same as the desired name of the generated binary. |
||
| srcs | label_list | [] |
The list of Go source files that are compiled to create the package.
Only .go and .s files are permitted, unless the cgo
attribute is set, in which case,
.c .cc .cpp .cxx .h .hh .hpp .hxx .inc .m .mm
files are also permitted. Files may be filtered at build time
using Go build constraints. |
||
| embedsrcs | label_list | [] |
The list of files that may be embedded into the compiled package using
//go:embed directives. All files must be in the same logical directory
or a subdirectory as source files. All source files containing //go:embed
directives must be in the same logical directory. It's okay to mix static and
generated source files and static and generated embeddable files. |
||
| deps | label_list | [] |
List of Go libraries this package imports directly.
These may be go_library rules or compatible rules with the GoLibrary provider. |
||
| embed | label_list | [] |
List of Go libraries whose sources should be compiled together with this
binary's sources. Labels listed here must name go_library,
go_proto_library, or other compatible targets with the GoLibrary and
GoSource providers. Embedded libraries must all have the same importpath,
which must match the importpath for this go_binary if one is
specified. At most one embedded library may have cgo = True, and the
embedding binary may not also have cgo = True. See Embedding for
more information. |
||
| data | label_list | [] |
| List of files needed by this rule at run-time. This may include data files needed or other programs that may be executed. The bazel package may be used to locate run files; they may appear in different places depending on the operating system and environment. See data dependencies for more information on data files. | ||
| importpath | string | "" |
| The import path of this binary. Binaries can't actually be imported, but this may be used by go_path and other tools to report the location of source files. This may be inferred from embedded libraries. | ||
| pure | string | auto |
Controls whether cgo source code and dependencies are compiled and linked,
similar to setting CGO_ENABLED. May be one of on, off,
or auto. If auto, pure mode is enabled when no C/C++
toolchain is configured or when cross-compiling. It's usually better to
control this on the command line with
--@io_bazel_rules_go//go/config:pure. See mode attributes, specifically
pure. |
||
| static | string | auto |
Controls whether a binary is statically linked. May be one of on,
off, or auto. Not available on all platforms or in all
modes. It's usually better to control this on the command line with
--@io_bazel_rules_go//go/config:static. See mode attributes,
specifically static. |
||
| race | string | auto |
Controls whether code is instrumented for race detection. May be one of
on, on, or auto. Not available when cgo is
disabled. In most cases, it's better to control this on the command line with
--@io_bazel_rules_go//go/config:race. See mode attributes, specifically
race. |
||
| msan | string | auto |
Controls whether code is instrumented for memory sanitization. May be one of
on, on, or auto. Not available when cgo is
disabled. In most cases, it's better to control this on the command line with
--@io_bazel_rules_go//go/config:msan. See mode attributes, specifically
msan. |
||
| gotags | string_list : [] |
|
| Enables a list of build tags when evaluating build constraints. Useful for conditional compilation. | ||
| goos | string | auto |
Forces a binary to be cross-compiled for a specific operating system. It's
usually better to control this on the command line with This disables cgo by default, since a cross-compiling C/C++ toolchain is rarely available. To force cgo, set pure = off. See Cross compilation for more information. |
||
| goarch | string | auto |
Forces a binary to be cross-compiled for a specific architecture. It's usually
better to control this on the command line with This disables cgo by default, since a cross-compiling C/C++ toolchain is rarely available. To force cgo, set pure = off. See Cross compilation for more information. |
||
| gc_goopts | string_list | [] |
| List of flags to add to the Go compilation command when using the gc compiler. Subject to "Make variable" substitution and Bourne shell tokenization. | ||
| gc_linkopts | string_list | [] |
| List of flags to add to the Go link command when using the gc compiler. Subject to "Make variable" substitution and Bourne shell tokenization. | ||
| x_defs | string_dict | {} |
| Map of defines to add to the go link command. See Defines and stamping for examples of how to use these. | ||
| cgo | boolean | False |
If True, the package may contain cgo code, and srcs may contain
C, C++, Objective-C, and Objective-C++ files and non-Go assembly files.
When cgo is enabled, these files will be compiled with the C/C++ toolchain
and included in the package. Note that this attribute does not force cgo
to be enabled. Cgo is enabled for non-cross-compiling builds when a C/C++
toolchain is configured. |
||
| cdeps | label_list | [] |
The list of other libraries that the c code depends on.
This can be anything that would be allowed in cc_library deps
Only valid if cgo = True. |
||
| copts | string_list | [] |
List of flags to add to the C compilation command.
Subject to "Make variable" substitution and Bourne shell tokenization.
Only valid if cgo = True. |
||
| cxxopts | string_list | [] |
List of flags to add to the C++ compilation command.
Subject to "Make variable" substitution and Bourne shell tokenization.
Only valid if cgo = True. |
||
| cppopts | string_list | [] |
List of flags to add to the C/C++ preprocessor command.
Subject to "Make variable" substitution and Bourne shell tokenization.
Only valid if cgo = True. |
||
| clinkopts | string_list | [] |
List of flags to add to the C link command.
Subject to "Make variable" substitution and Bourne shell tokenization.
Only valid if cgo = True. |
||
| linkmode | string | "normal" |
Determines how the binary should be built and linked. This accepts some of
the same values as
|
||
| out | string | "" |
Sets the output filename for the generated executable. When set, go_binary
will write this file without mode-specific directory prefixes, without
linkmode-specific prefixes like "lib", and without platform-specific suffixes
like ".exe". Note that without a mode-specific directory prefix, the
output file (but not its dependencies) will be invalidated in Bazel's cache
when changing configurations. |
||
This builds a set of tests that can be run with bazel test.
To run all tests in the workspace, and print output on failure (the
equivalent of go test ./...), run
bazel test --test_output=errors //...
To run a Go benchmark test, run
bazel run //path/to:test -- -test.bench=.
You can run specific tests by passing the --test_filter=pattern argument to Bazel. You can pass arguments to tests by passing --test_arg=arg arguments to Bazel, and you can set environment variables in the test environment by passing --test_env=VAR=value.
To write structured testlog information to Bazel's XML_OUTPUT_FILE, tests
ran with bazel test execute using a wrapper. This functionality can be
disabled by setting GO_TEST_WRAP=0 in the test environment. Additionally,
the testbinary can be invoked with -test.v by setting
GO_TEST_WRAP_TESTV=1 in the test environment; this will result in the
XML_OUTPUT_FILE containing more granular data.
| Name | Type | Default value |
| name | string | mandatory value |
A unique name for this rule. To interoperate cleanly with old targets generated by Gazelle this
should be |
||
| srcs | label_list | [] |
The list of Go source files that are compiled to create the package.
Only .go and .s files are permitted, unless the cgo
attribute is set, in which case,
.c .cc .cpp .cxx .h .hh .hpp .hxx .inc .m .mm
files are also permitted. Files may be filtered at build time
using Go build constraints. |
||
| deps | label_list | [] |
| List of Go libraries this test imports directly. These may be go_library rules or compatible rules with the GoLibrary provider. | ||
| env | string_dict | {} |
| Environment variables to set for the test execution. The values (but not keys) are subject to [location expansion](https://docs.bazel.build/versions/main/skylark/macros.html) but not full [make variable expansion](https://docs.bazel.build/versions/main/be/make-variables.html). | ||
| embed | label_list | [] |
List of Go libraries whose sources should be compiled together with this
package's sources. Labels listed here must name go_library,
go_proto_library, or other compatible targets with the GoLibrary and
GoSource providers. Embedded libraries must have the same importpath as
the embedding library. At most one embedded library may have cgo = True,
and the embedding library may not also have cgo = True. See Embedding
for more information. |
||
| embedsrcs | label_list | [] |
The list of files that may be embedded into the compiled package using
//go:embed directives. All files must be in the same logical directory
or a subdirectory as source files. All source files containing //go:embed
directives must be in the same logical directory. It's okay to mix static and
generated source files and static and generated embeddable files. |
||
| data | label_list | [] |
| List of files needed by this rule at run-time. This may include data files needed or other programs that may be executed. The bazel package may be used to locate run files; they may appear in different places depending on the operating system and environment. See data dependencies for more information on data files. | ||
| importpath | string | "" |
| The import path of this test. Tests can't actually be imported, but this may be used by go_path and other tools to report the location of source files. This may be inferred from embedded libraries. | ||
| pure | string | auto |
Controls whether cgo source code and dependencies are compiled and linked,
similar to setting CGO_ENABLED. May be one of on, off,
or auto. If auto, pure mode is enabled when no C/C++
toolchain is configured or when cross-compiling. It's usually better to
control this on the command line with
--@io_bazel_rules_go//go/config:pure. See mode attributes, specifically
pure. |
||
| static | string | auto |
Controls whether a binary is statically linked. May be one of on,
off, or auto. Not available on all platforms or in all
modes. It's usually better to control this on the command line with
--@io_bazel_rules_go//go/config:static. See mode attributes,
specifically static. |
||
| race | string | auto |
Controls whether code is instrumented for race detection. May be one of
on, on, or auto. Not available when cgo is
disabled. In most cases, it's better to control this on the command line with
--@io_bazel_rules_go//go/config:race. See mode attributes, specifically
race. |
||
| msan | string | auto |
Controls whether code is instrumented for memory sanitization. May be one of
on, on, or auto. Not available when cgo is
disabled. In most cases, it's better to control this on the command line with
--@io_bazel_rules_go//go/config:msan. See mode attributes, specifically
msan. |
||
| gotags | string_list : [] |
|
| Enables a list of build tags when evaluating build constraints. Useful for conditional compilation. | ||
| goos | string | auto |
Forces a binary to be cross-compiled for a specific operating system. It's
usually better to control this on the command line with This disables cgo by default, since a cross-compiling C/C++ toolchain is rarely available. To force cgo, set pure = off. See Cross compilation for more information. |
||
| goarch | string | auto |
Forces a binary to be cross-compiled for a specific architecture. It's usually
better to control this on the command line with This disables cgo by default, since a cross-compiling C/C++ toolchain is rarely available. To force cgo, set pure = off. See Cross compilation for more information. |
||
| gc_goopts | string_list | [] |
| List of flags to add to the Go compilation command when using the gc compiler. Subject to "Make variable" substitution and Bourne shell tokenization. | ||
| gc_linkopts | string_list | [] |
| List of flags to add to the Go link command when using the gc compiler. Subject to "Make variable" substitution and Bourne shell tokenization. | ||
| x_defs | string_dict | {} |
| Map of defines to add to the go link command. See Defines and stamping for examples of how to use these. | ||
| cgo | boolean | False |
If True, the package may contain cgo code, and srcs may contain
C, C++, Objective-C, and Objective-C++ files and non-Go assembly files.
When cgo is enabled, these files will be compiled with the C/C++ toolchain
and included in the package. Note that this attribute does not force cgo
to be enabled. Cgo is enabled for non-cross-compiling builds when a C/C++
toolchain is configured. |
||
| cdeps | label_list | [] |
The list of other libraries that the c code depends on.
This can be anything that would be allowed in cc_library deps
Only valid if cgo = True. |
||
| copts | string_list | [] |
List of flags to add to the C compilation command.
Subject to "Make variable" substitution and Bourne shell tokenization.
Only valid if cgo = True. |
||
| cxxopts | string_list | [] |
List of flags to add to the C++ compilation command.
Subject to "Make variable" substitution and Bourne shell tokenization.
Only valid if cgo = True. |
||
| cppopts | string_list | [] |
List of flags to add to the C/C++ preprocessor command.
Subject to "Make variable" substitution and Bourne shell tokenization.
Only valid if cgo = True. |
||
| clinkopts | string_list | [] |
List of flags to add to the C link command.
Subject to "Make variable" substitution and Bourne shell tokenization.
Only valid if cgo = True. |
||
| rundir | string | The package path |
A directory to cd to before the test is run. This should be a path relative to the execution dir of the test. The default behaviour is to change to the workspace relative path, this replicates the normal
behaviour of Setting it to |
||
| shard_count | integer | None |
Non-negative integer less than or equal to 50, optional. Specifies the number of parallel shards to run the test. Test methods will be split across the shards in a round-robin fashion. For more details on this attribute, consult the official Bazel documentation for shard_count. |
||
To write an internal test, reference the library being tested with the embed instead of deps. This will compile the test sources into the same package as the library sources.
This builds a test that can use the internal interface of the package being tested.
In the normal go toolchain this would be the kind of tests formed by adding writing
<file>_test.go files in the same package.
It references the library being tested with embed.
go_library(
name = "lib",
srcs = ["lib.go"],
)
go_test(
name = "lib_test",
srcs = ["lib_test.go"],
embed = [":lib"],
)This builds a test that can only use the public interface(s) of the packages being tested.
In the normal go toolchain this would be the kind of tests formed by adding an <name>_test
package.
It references the library(s) being tested with deps.
go_library(
name = "lib",
srcs = ["lib.go"],
)
go_test(
name = "lib_xtest",
srcs = ["lib_x_test.go"],
deps = [":lib"],
)This declares a set of source files and related dependencies that can be embedded into one of the other rules. This is used as a way of easily declaring a common set of sources re-used in multiple rules.
| Name | Type | Default value |
| name | string | mandatory value |
| A unique name for this rule. | ||
| srcs | label_list | [] |
The list of Go source files that are compiled to create the package.
The following file types are permitted: .go, .c, .s, .S .h.
The files may contain Go-style build constraints. |
||
| deps | label_list | [] |
| List of Go libraries this source list imports directly. These may be go_library rules or compatible rules with the GoLibrary provider. | ||
| embed | label_list | [] |
List of Go libraries whose sources should be compiled together with this
package's sources. Labels listed here must name go_library,
go_proto_library, or other compatible targets with the GoLibrary and
GoSource providers. Embedded libraries must have the same importpath as
the embedding library. At most one embedded library may have cgo = True,
and the embedding library may not also have cgo = True. See Embedding
for more information. |
||
| data | label_list | [] |
| List of files needed by this rule at run-time. This may include data files needed or other programs that may be executed. The bazel package may be used to locate run files; they may appear in different places depending on the operating system and environment. See data dependencies for more information on data files. | ||
| gc_goopts | string_list | [] |
| List of flags to add to the Go compilation command when using the gc compiler. Subject to "Make variable" substitution and Bourne shell tokenization. | ||
go_path builds a directory structure that can be used with tools that
understand the GOPATH directory layout. This directory structure can be
built by zipping, copying, or linking files.
go_path can depend on one or more Go targets (i.e., go_library,
go_binary, or go_test). It will include packages from those targets, as
well as their transitive dependencies. Packages will be in subdirectories named
after their importpath or importmap attributes under a src/
directory.
| Name | Type | Default value |
| name | string | mandatory value |
| A unique name for this rule. | ||
| deps | label_list | [] |
A list of targets that build Go packages. A directory will be generated from files in these targets and their transitive dependencies. All targets must provide GoArchive (go_library, go_binary, go_test, and similar rules have this). Only targets with explicit The generated directory will contain original source files, including .go,
.s, .h, and .c files compiled by cgo. It will not contain files generated by
tools like cover and cgo, but it will contain generated files passed in
|
||
| data | label_list | [] |
A list of targets producing data files that will be stored next to the
src/ directory. Useful for including things like licenses and readmes. |
||
| mode | string | "copy" |
Determines how the generated directory is provided. May be one of:
NOTE: In |
||
| include_data | bool | True |
| When true, data files referenced by libraries, binaries, and tests will be included in the output directory. Files listed in the data attribute for this rule will be included regardless of this attribute. | ||
| include_pkg | bool | False |
| When true, a pkg subdirectory containing the compiled libraries will be created in the generated GOPATH containing compiled libraries. | ||
| include_transitive | bool | True |
| When true, the transitive dependency graph will be included in the generated GOPATH. This is the default behaviour. When false, only the direct dependencies will be included in the generated GOPATH. | ||
In order to provide build time information to go code without data files, we support the concept of stamping.
Stamping asks the linker to substitute the value of a global variable with a string determined at link time. Stamping only happens when linking a binary, not when compiling a package. This means that changing a value results only in re-linking, not re-compilation and thus does not cause cascading changes.
Link values are set in the x_defs attribute of any Go rule. This is a map of string to string, where keys are the names of variables to substitute, and values are the string to use. Keys may be names of variables in the package being compiled, or they may be fully qualified names of variables in another package.
These mappings are collected up across the entire transitive dependencies of a
binary. This means you can set a value using x_defs in a
go_library, and any binary that links that library will be stamped with that
value. You can also override stamp values from libraries using x_defs
on the go_binary rule if needed. The --[no]stamp option controls whether
stamping of workspace variables is enabled.
Example
Suppose we have a small library that contains the current version.
package version
var Version = "redacted"We can set the version in the go_library rule for this library.
go_library(
name = "version",
srcs = ["version.go"],
importpath = "example.com/repo/version",
x_defs = {"Version": "0.9"},
)Binaries that depend on this library may also set this value.
go_binary(
name = "cmd",
srcs = ["main.go"],
deps = ["//version"],
x_defs = {"example.com/repo/version.Version": "0.9"},
)You can use values produced by the workspace status command in your link stamp. To use this functionality, write a script that prints key-value pairs, separated by spaces, one per line. For example:
#!/usr/bin/env bash
echo STABLE_GIT_COMMIT $(git rev-parse HEAD)NOTE: keys that start with STABLE_ will trigger a re-link when they change.
Other keys will NOT trigger a re-link.
You can reference these in x_defs using curly braces.
go_binary(
name = "cmd",
srcs = ["main.go"],
deps = ["//version"],
x_defs = {"example.com/repo/version.Version": "{STABLE_GIT_COMMIT}"},
)You can build using the status script using the --workspace_status_command
argument on the command line:
$ bazel build --stamp --workspace_status_command=./status.sh //:cmdThe sources, dependencies, and data of a go_library may be embedded
within another go_library, go_binary, or go_test using the embed
attribute. The embedding package will be compiled into a single archive
file. The embedded package may still be compiled as a separate target.
A minimal example of embedding is below. In this example, the command bazel
build :foo_and_bar will compile foo.go and bar.go into a single
archive. bazel build :bar will compile only bar.go. Both libraries must
have the same importpath.
go_library(
name = "foo_and_bar",
srcs = ["foo.go"],
embed = [":bar"],
importpath = "example.com/foo",
)
go_library(
name = "bar",
srcs = ["bar.go"],
importpath = "example.com/foo",
)Embedding is most frequently used for tests and binaries. Go supports two
different kinds of tests. Internal tests (e.g., package foo) are compiled
into the same archive as the library under test and can reference unexported
definitions in that library. External tests (e.g., package foo_test) are
compiled into separate archives and may depend on exported definitions from the
internal test archive.
In order to compile the internal test archive, we embed the go_library
under test into a go_test that contains the test sources. The go_test
rule can automatically distinguish internal and external test sources, so they
can be listed together in srcs. The go_library under test does not
contain test sources. Other go_binary and go_library targets can depend
on it or embed it.
go_library(
name = "foo_lib",
srcs = ["foo.go"],
importpath = "example.com/foo",
)
go_binary(
name = "foo",
embed = [":foo_lib"],
)
go_test(
name = "go_default_test",
srcs = [
"foo_external_test.go",
"foo_internal_test.go",
],
embed = [":foo_lib"],
)Embedding may also be used to add extra sources sources to a
go_proto_library.
proto_library(
name = "foo_proto",
srcs = ["foo.proto"],
)
go_proto_library(
name = "foo_go_proto",
importpath = "example.com/foo",
proto = ":foo_proto",
)
go_library(
name = "foo",
srcs = ["extra.go"],
embed = [":foo_go_proto"],
importpath = "example.com/foo",
)rules_go can cross-compile Go projects to any platform the Go toolchain
supports. The simplest way to do this is by setting the --platforms flag on
the command line.
$ bazel build --platforms=@io_bazel_rules_go//go/toolchain:linux_amd64 //my/project
You can replace linux_amd64 in the example above with any valid
GOOS / GOARCH pair. To list all platforms, run this command:
$ bazel query 'kind(platform, @io_bazel_rules_go//go/toolchain:all)'
By default, cross-compilation will cause Go targets to be built in "pure mode", which disables cgo; cgo files will not be compiled, and C/C++ dependencies will not be compiled or linked.
Cross-compiling cgo code is possible, but not fully supported. You will need to
write a CROSSTOOL file that describes your C/C++ toolchain. You'll need to
ensure it works by building cc_binary and cc_library targets with the
--cpu command line flag set. Then, to build a mixed Go / C / C++ project,
add pure = "off" to your go_binary target and run Bazel with --cpu
and --platforms.
When cross-compiling, you may have some platform-specific sources and
dependencies. Source files from all platforms can be mixed freely in a single
srcs list. Source files are filtered using build constraints (filename
suffixes and +build tags) before being passed to the compiler.
Platform-specific dependencies are another story. For example, if you are building a binary for Linux, and it has dependency that should only be built when targeting Windows, you will need to filter it out using Bazel select expressions:
go_binary(
name = "cmd",
srcs = [
"foo_linux.go",
"foo_windows.go",
],
deps = [
# platform agnostic dependencies
"//bar",
] + select({
# OS-specific dependencies
"@io_bazel_rules_go//go/platform:linux": [
"//baz_linux",
],
"@io_bazel_rules_go//go/platform:windows": [
"//quux_windows",
],
"//conditions:default": [],
}),
)select accepts a dictionary argument. The keys are labels that reference
config_setting rules. The values are lists of labels. Exactly one of these
lists will be selected, depending on the target configuration. rules_go has
pre-declared config_setting rules for each OS, architecture, and
OS-architecture pair. For a full list, run this command:
$ bazel query 'kind(config_setting, @io_bazel_rules_go//go/platform:all)'
Gazelle will generate dependencies in this format automatically.