Comments (6)
but I was hoping to make it work in more bazel-native way...
With standard go toolchain, and go.env file, it is easy to set all the env vars in one place.
I found these two requirements contradicting. Bazel doesn't use the go
command from Go toolchain to compile and link. So even with what @fmeum did in #3879, the envs only affects the go
command, not the compilation and linking.
In fact, I am worried that go_sdk.config(go_env = {...})
gives users a false impression that they can control compilation and linking by setting things likeCGO_CFLAGS
or GOOS
there.
So I think the "bazel-native way" is to set the envs in different ways than Go:
- GOPROXY can potentially be set with
gazelle_dependencies(go_env = ...)
like @fmeum in #3879, but we found it working well to set it in Bazel wrapper (e.g. tools/bazel) - GOOS is set with
--platforms
- CXX, CC should be the C toolchain resolved by Bazel
GOFLAGS
should be set from--@io_bazel_rules_go//go/config:gc_goopts
- This goes on and on...
What I am trying to say is Bazel and Go are two fundamentally different build systems. The behavior of Go build is controlled by env vars, but Bazel prefers configuration files and command line flags.
from rules_go.
Another thought after looking at golang/go@7aa85e0
Should go_register_toolchains
just allow to specify go.env
file?
https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst#go-register-toolchains
Maybe #3401 should be further generalized to all go env vars?
from rules_go.
Should go_register_toolchains just allow to specify go.env file?
This was actually my first thought as well, but I now see undesirable side effects: The env variables one typically wants to set affect the fetches of dependencies, but not the compilation of .go
code itself. If we add these variables to the go.env
of the Go SDK, they will be an input to compilation actions and thus affect cache hits.
Instead, we can forward the variables to only the two places related to dependency fetching: @rules_go//go
and go_repository
.
from rules_go.
@fmeum:
https://pkg.go.dev/cmd/go#hdr-Environment_variables
lists all possible variables, and it seems like is not just about fetches of dependencies.
With standard go toolchain, and go.env file, it is easy to set all the env vars in one place.
But with Bazel some of them can be set by these settings:
https://github.com/bazelbuild/rules_go/blob/master/go/modes.rst#build-settings
Some are chosen for you by rules_go for you:
https://github.com/bazelbuild/rules_go/blame/55ea579a70958d66f24a907433978b21edd36b29/go/private/sdk.bzl#L491
So maybe allowing to specify all env vars in a single place will ease the mental load of users?
from rules_go.
@linzhp makes a very good point. I will change the name of the go_env
attribute to something like go_fetch_env
to make it clear that build-related env vars won't be read.
from rules_go.
I submitted bazelbuild/bazel-gazelle#1748 instead, which moves the new go_env
field to go_deps
, hopefully making it more clear that this is only targetted at fetching of Go deps. What do you think?
from rules_go.
Related Issues (20)
- setting `extldflags` as flag does not parse properly HOT 1
- nogo not populating Go version in analysis pass
- Hello World for Golang is a bit difficult.
- gc_goopts seems buggy or has unexpected behavior
- Unable to get io_bazel_rules_go to work with a custom c++ toolchain HOT 1
- Rules_go 0.47.0 downgraded the gomock dependency from 1.7.0-rc1 to 1.6.0, which broke support for generics in mocks HOT 1
- How to test an analysis.Analyzer?
- Differentiate compile actions under go_test
- `GoLink` for Gazelle fails on Go 1.20 or greater HOT 2
- goleak broken by recent timeout changes
- How do I depend on the "bazel" package of rules_go when using MODULE.bazel HOT 3
- [BAZEL CI] rules_go cgo:opts_test is failing with Bazel@HEAD HOT 1
- go_tool_binary / GoToolchainBinaryBuild actions don't always run on the correct platform
- GoStdlib, GoCompilePkg, etc. don't respect exec_compatible_with of the underlying C/C++ toolchain HOT 1
- Calls to https://go.dev/dl/?mode=json are breaking airgapped builds - provide way to avoid these HOT 6
- rules_go + protobufs + experimental_sibling_repository_layout fails to build HOT 2
- How do you use protoc with 0.48.0? HOT 4
- Proposal: Fail protoc code gen on missing expected output files
- Embedding native buildinfo in Bazel binaries
- go_proto_library: Issue/New Feature for output path generation.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rules_go.