When building with blueprint, go 1.22 will be used, but if you used
go build or go test manually, the version in the go.mod will be used.
Go 1.22 has a subtle change that we want to make sure we're always
using: https://go.dev/blog/loopvar-preview
Bug: 330574836
Test: Presubmits
Change-Id: Idf46b77c4f817345c1f9aca039d8735bb101967f
Code in build/soong is using new builtins like max, update go.work
and go.mod to require 1.21 so that go test ./... works.
Fixes:
ui/status/ninja.go:193:25: max requires go1.21 or later (-lang was set to go1.20; check go.mod)
Test: go test ./...
Change-Id: I38f1a2298937db0d7c741b2183540fa3d02dac79
Use Go's generics for DepSets so they don't require a type-specific
wrapper and reflection.
Test: depsets_test.go
Change-Id: I22ba0b7d680d37d2cd05230b0f560d166c4dd20b
There are a number of instances where we are exporting information
from soong to bazel via soong_injection. This could be more bazel-centric
if the information was instead held in bzl files, and both bazel and
soong read it from there.
Add a starlark package that will run
//build/bazel/constants_exported_to_soong.bzl at initialization time,
and then results can be retreived with GetStarlarkValue.
Since changes to the starlark files mean that soong has to rerun,
add them as ninja deps.
Unfortunately, the starlark code has to be run at runtime rather than
pregenerating their results, because tests run from intellij wouldn't
go through any pregeneration steps. This means that starlark is run
multiple times during the build, once per test package and once per
primary builder invocation. (currently 3, could be reduced to 2 if we
made the symlink forest generation into its own standalone tool) The
starlark code we have so far in this cl is very fast, roughly half a
millisecond, so it's not a big deal for now, but something to keep an
eye on as we add more starlark constants.
Bug: 279095899
Test: go test
Change-Id: I1e7ca1df1d8d67333cbfc46e8396e229820e4476
Note go.mod file changes go version to 1.18 (for generics)
You might need to refresh/reload your IDE (e.g. IntelliJ)
Bug: N/A
Test: manually verified (e.g. ran `m nothing` successfully)
Change-Id: I2a6dadd673fd170961d1fd1e1756f7581e9a1091
The golang-protobuf upgrade brought in new dependencies, which broke the
hermeticity of our go.mod redirections. Fix those up so they get
excluded or redirected to the locations in the tree.
Test: cd build/soong/cc; go test .
Change-Id: I012d11fad3b5509b213093e3c5889a27e641b868
Major operations:
* Fix the go_package entries to be consistent, as the new tool
complains when it doesn't have a '/'.
* Regenerate with the new protoc-gen-go tool.
* github.com/golang/protobuf -> google.golang.org/protobuf
* proto.[Un]MarshalText -> prototext.[Un]Marshal
Change-Id: Ie1147bd2457fafb66ba555461b3bf14f0561a25d
This reverts commit 23f69ae958.
Reason for revert: invalid go version '1.15.6': must match format 1.23
Change-Id: Ibe4335f4d9b3ff4b08b4615b91935cca4643ee89
The version in go.mod is used by `go build` to select the version
of the Go language to target. If it is older than the version of Go
in the tree then command line tools like `go test` will give different
results from inside the build. Update the version to match the version
of Go in the tree.
Test: go build ./java
Change-Id: I418f401580be7696e2829c970938c7c82715b932
With this and go1.11beta2, the standard go tools can be used in
build/soong without creating a $GOPATH using something like
setup_go_workspace_for_soong.
Test: go vet android/soong/...
Change-Id: I3c69499b010c8f7f64666208efead4ddb3584b3c
