| Age | Commit message (Collapse) | Author |
|---|
|
PiperOrigin-RevId: 338739277
|
|
PiperOrigin-RevId: 338517024
|
|
PiperOrigin-RevId: 337968219
|
|
Using the newer bazel rules necessitates a transition from proto1 to
proto2. In order to resolve the incompatibility between proto2 and
gogoproto, the cri runtimeoptions proto must be vendored.
Further, some of the semantics of bazel caching changed during the
transition. It is now necessary to:
- Ensure that :gopath depends only on pure library targets, as the
propagation of go_binary build attributes (pure, static) will
affected the generated files (though content remains the same,
there are conflicts with respect to the gopath).
- Update bazel.mk to include the possibility of binaries in the
bazel-out directory, as it will now put runsc and others there.
This required some refinements to the mechanism of extracting
paths, since some the existing regex resulted in false positives.
- Change nogo rules to prevent escape generation on binary targets.
For some reason, the newer version of bazel attempted to run the
nogo analysis on the binary targets, which fails due to the fact
that objdump does not work on the final binary. This must be due
to a change in the semantics of aspects in bazel3.
PiperOrigin-RevId: 337958324
|
|
PiperOrigin-RevId: 324022546
|
|
PiperOrigin-RevId: 323646156
|
|
PiperOrigin-RevId: 323454998
|
|
PiperOrigin-RevId: 308901116
|
|
PiperOrigin-RevId: 291745021
|
|
Also add our RBE project/instance to the --config=remote defaults.
PiperOrigin-RevId: 291201426
|
|
This will require a reasonably modern toolchain. I've put minimum compiler
versions in the README based on versions in
https://en.cppreference.com/w/cpp/compiler_support that have mostly complete
language and library support.
The minimum Bazel version bump is unrelated, but 0.28 is definitely not
supported anymore.
Please report issues on gvisor.dev/issue/1349.
Fixes #1349
PiperOrigin-RevId: 284274250
|
|
We need to include the `--stamp` flag in `tools/workspace_status.sh` for
the version to be picked up by the linker. Not sure why.
Also changes the VERSION string to STABLE_VERSION, which will cause the
program to be re-linked if the string changes.
Fixes #830
|
|
The new version has a change in behavior when using a custom platform:
* Old behavior: rules that don't require a toolchain used host_platform, no
matter what execution platforms are specified.
* New behavior: rules that don't require a toolchain use standard platform
resolution that starts with execution platforms.
As part of this change, we cannot use the "extra_exectution_platforms" flag
provided by the default bazelrc. I got rid of the default bazelrc file, and
made our custom .bazelrc as minimal as possible.
PiperOrigin-RevId: 263176802
|
|
Updates #209
PiperOrigin-RevId: 251289513
|
|
This CL merges all RBE-specific configuration from .bazelrc_rbe into .bazelrc
so that it will be picked up by default by users running bazel.
It also checks in a bazelrc from the upstream bazel-toolchains repository, and
imports that into our repo-specific .bazelrc. This makes it easier to maintain
and update the bazelrc going forward.
Documentation was added to the README.
PiperOrigin-RevId: 242208733
Change-Id: Iea32de9be85b024bd74f88909b56b2a8ab34851a
|
|
Bazel 0.18 moved the workspace bazelrc location from //tools/bazel.rc to
//.bazelrc. The old location will be dropped by a future version of
bazel.
This bumps the minimum required version of bazel to 0.18.
More context:
https://groups.google.com/forum/#!msg/bazel-discuss/ycDacctX2vw/EGFxGLibAgAJ
PiperOrigin-RevId: 220338084
Change-Id: Ib6fa83a4a0f89e8e898d67152c7bd429e0b9b21e
|
