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
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
