- point to bazelbuild/platforms for @platforms
- Use a newer version of rules_go for our internal rules.
- Make a bzl file used in a test visible to the tests.
I believe this fixes a build breakage in bazel at head and 5.3.0
They are now part of the bazelbuild/bazel repository.
Copies buildifier changes contributed by Keith in https://github.com/bazelbuild/rules_cc/pull/128
RELNOTES:none
PiperOrigin-RevId: 435312636
Change-Id: I4d5d2f58d90026c0cdfb5c0a90709de7c28c6ccd
- bazel presumed a trailing space in `clang-cl -v` output that is
no longer present in the 11.0.0 release, resulting in an injected newline
Co-authored-by: Sunjay Bhatia <sunjayb@vmware.com>
Co-authored-by: William A Rowe Jr <wrowe@vmware.com>
Signed-off-by: Sunjay Bhatia <sunjayb@vmware.com>
Signed-off-by: William A Rowe Jr <wrowe@vmware.com>
These are used throughout the Crosstool features definitions based on local definitions there. It seems useful to move these to a common location so they are available for other toolchains (and also so that they get updated if new actions are added to the action-name list).
The versions of these currently used by Crosstool are defined in //third_party/crosstool/v18/llvm_unstable/crosstool_helpers.bzl starting at line 124.
Tested:
by inspection
PiperOrigin-RevId: 339440647
Change-Id: I3a2b8d37aebd8a0e8450864e079cf5b42d075def
This is phase 2 of of the switch to toolchain transitions. See https://github.com/bazelbuild/bazel/issues/11584 for details.
PiperOrigin-RevId: 334808134
Change-Id: Ie198b07359d4fd45368755c4cc223e397f0e8fb0
This allows setting GCOV on the command line to overwrite the default setting, which points to /usr/bin/gcov. In order to use this, you also need to disable the gcov coverage feature and enable the llvm coverage feature instead. The full command-line looks like this:
GCOV=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/llvm-profdata bazel coverage --features=llvm_coverage_map_format --features=-gcc_coverage_map_format //cpp:test
Progress on #10457.
Original change by ulfjack
RELNOTES: None.
PiperOrigin-RevId: 300583709
Change-Id: Ibeda8469db6750fc9fc3bba60e19118a2e482ed8
Default linker flags contains flags like -lstdc++ which should come after the
user libraries. The library flags are removed from default linker flags and added to link_libs instead which comes after user libraries.
See #9254
Incompatible flag bug: https://github.com/bazelbuild/bazel/issues/10905
I introduce a new method to repositories ctx that allows checking the value of a Starlark semantic option from a repository rule.
RELNOTES:none
PiperOrigin-RevId: 299336105
Change-Id: I81b9ee0c72e2a2252b406f1c584997389a530e40
For now we will restrict allowed exports to the same package. At the same time
static_deps should be used to take into account what should be linked into a
shared library.
RELNOTES:none
PiperOrigin-RevId: 294668451
Change-Id: Ia087519106983bfa9a980e471d3102ab391a53eb
When adding tags to a native cc_library rule that is created through a macro we
were not properly considering the case where the tags came from a different
file and therefore were frozen. This caused an error.
RELNOTES:none
PiperOrigin-RevId: 283039855
Change-Id: Id4cb45675a08ca65196f4f7771abdd5bb0705b79
We're working on removing C++ toolchain autoconfiguration logic out of Bazel,
and moving towards using rules_cc repository for it. Some bzl files will no
longer be available through bazel/tools/cpp/*, but through
@rules_cc/cc/*.
RELNOTES: None.
PiperOrigin-RevId: 279935457
Change-Id: I3bae259548dacc5c6789efe0f27dd07738c1057c
Labels in toolchains attribute need to include the repository, otherwise the resolution won't work.
RELNOTES: None.
PiperOrigin-RevId: 279347045
Change-Id: Iba1eb8bb677771e2c089ab6bc1b5e019c4da434e
Tony Aiuto