go_binary: support build constraints via build_setting #1351
Labels
Milestone
Comments
justinsb
changed the title
|
Build tags aren't actually supported yet. Our compiler wrapper filters source files using tags, but it doesn't have any way to turn on custom tags. #1340 should add some support for this, plus several other changes. You'll pass This assumes that tags pull in alternate files that aren't normally required, e.g., extra debug or profiling code. If you have a library that requires tags to build, maybe we can add a Note that the |
jayconrod
changed the title
|
#2219 will provide a framework for supporting this. |
jayconrod
pushed a commit
that referenced
this issue
Mar 26, 2020
This changes how the goos, goarch, race, msan, static, and pure attributes of go_binary and go_test are implemented. Previously, the go_binary and go_test rules used an aspect on the deps and embed attributes. If any of the mode attributes listed above were set, the aspect declared additional output files and actions to generate them for the specified configuration. This approach had two significant problems. First, the aspect caused the analysis to be performed twice, wasting time and memory even in the case where no cross-compilation was needed. Second, the aspect was not compatible with conditional dependencies specified with select expressions: aspects run on the configured target graph, but the mode attributes could not affect Bazel's configuration. This change deletes the aspect and implements these attributes using a different mechanism: build settings and configuration transitions. A new package is added //go/config with a build setting for each attribute. Most settings are flags that may be set on the command-line. This is an alternative to --feature flags, which will be deprecated and eventually removed. The target //:go_config gathers build settings relevant to Go and provides a GoContextInfo (private). The target //:go_context_data depends on //:go_config, //:stdlib, //:nogo, and a few other standard dependencies. go_binary and go_test rules no longer need to depend on these targets directly. Go rules should now only need to depend on //:go_context_data and the Go toolchain. Unfortunately, neither //:go_context_data nor //:go_config can be part of the toolchain because the toolchain is always analyzed for the execution configuration, not the target configuration. Because of the simplified dependencies, the go_rule function is no longer needed by most rules. This change makes it possible to deprecate it. Fixes #1351 Fixes #2219 Updates #2302
jayconrod
pushed a commit
that referenced
this issue
Apr 17, 2020
This changes how the goos, goarch, race, msan, static, and pure attributes of go_binary and go_test are implemented. Previously, the go_binary and go_test rules used an aspect on the deps and embed attributes. If any of the mode attributes listed above were set, the aspect declared additional output files and actions to generate them for the specified configuration. This approach had two significant problems. First, the aspect caused the analysis to be performed twice, wasting time and memory even in the case where no cross-compilation was needed. Second, the aspect was not compatible with conditional dependencies specified with select expressions: aspects run on the configured target graph, but the mode attributes could not affect Bazel's configuration. This change deletes the aspect and implements these attributes using a different mechanism: build settings and configuration transitions. A new package is added //go/config with a build setting for each attribute. Most settings are flags that may be set on the command-line. This is an alternative to --feature flags, which will be deprecated and eventually removed. The target //:go_config gathers build settings relevant to Go and provides a GoContextInfo (private). The target //:go_context_data depends on //:go_config, //:stdlib, //:nogo, and a few other standard dependencies. go_binary and go_test rules no longer need to depend on these targets directly. Go rules should now only need to depend on //:go_context_data and the Go toolchain. Unfortunately, neither //:go_context_data nor //:go_config can be part of the toolchain because the toolchain is always analyzed for the execution configuration, not the target configuration. Because of the simplified dependencies, the go_rule function is no longer needed by most rules. This change makes it possible to deprecate it. Fixes #1351 Fixes #2219 Updates #2302
jayconrod
pushed a commit
to jayconrod/rules_go
that referenced
this issue
Apr 17, 2020
The gotags attribute sets which build tags are enabled when evaluting build constraints. This is equivalent to setting --@io_bazel_rules_go//go/config:tags on the command line. Fixes bazel-contrib#1351
jayconrod
pushed a commit
that referenced
this issue
Apr 20, 2020
The gotags attribute sets which build tags are enabled when evaluting build constraints. This is equivalent to setting --@io_bazel_rules_go//go/config:tags on the command line. Fixes #1351
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have a library which requires custom build tags to build it (because there are two modes of operation, and we switch between them using build tags).
Specifically, if building from make I need to do this:
go build -o $@ -tags 'peer_name_alternative peer_name_hash' k8s.io/kops/protokube/cmd/protokubeWhen I try what I believe to be the equivalent syntax with bazel the tags appear to be ignored - they aren't visible on the command line with
bazel build -sfor example, and I get a compilation error that suggests the code was ignored.I'm adding this to go_library:
tags = [ "peer_name_alternative", "peer_name_hash" ], # keep. Actual code is here: https://github.com/kubernetes/kops/pull/4514/filesIs there a different place / way I should be passing the tags?
The text was updated successfully, but these errors were encountered: