- 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
--//examples:incompatible_link_once=False[default = False]
When True, it will be an error to link the same library more than once
unless it has the tag LINKABLE_MORE_THAN_ONCE
--//examples:experimental_debug=True[default = False]
When True, it will generate files listing the exports of each cc_shared_library
and which libraries are linked to it statically.
RELNOTES:none
PiperOrigin-RevId: 311323625
Change-Id: I340cc71965650f7c9dd7ef7fb9656da362021527
Changes in this CL:
1. 'exports' attribute renamed to roots
2. Removed restrictions for exporting a rule in a different repository
3. Kept restrictions for rules in the same repository but not in the same
package or subpackages
4. To get around restrictions, instead of the exported_by tag, one can use the
cc_shared_library_permissions rule
5. Added exports_filter that will match libraries in the transitive closure of
a root. Anything matched by the exports_filter will also be exported.
Restrictions as in 4. still apply.
RELNOTES:none
PiperOrigin-RevId: 310547916
Change-Id: I32d8e0d4dd4bcc9c9e92f4ff3c5b2a01564c31b2
This change adds an optional field to the C++ crosstool proto that
allows configuring the origin tool_path is relative to.
For now, the origin can be one of the following:
- CROSSTOOL_PACKAGE: If tool_path is a relative path, it's assumed to
be relative to the package of the crosstool top.
- FILESYSTEM_ROOT: tool_path is an absolute path. This is checked by
Bazel.
- WORKSPACE_ROOT: tool_path must be a relative path and is assumed to
be relative to the exec-root of the workspace (similar to other
executables).
Updates bazelbuild/bazel#8438
Closes #10967.
PiperOrigin-RevId: 310142352
Change-Id: If6316ffa5d7d2713b197840b4aafb2f0cdbb0b96
We were returning false when checking whether //foo:bar is under
//:__subpackages__
RELNOTES:none
PiperOrigin-RevId: 307808962
Change-Id: I080e4c239b75c188dae8af89f4b38aa935d92b0d
1. Don't pop from the front of the list being iterated on
2. Don't visit the same node_label more than once
RELNOTES:none
PiperOrigin-RevId: 307610981
Change-Id: I9b35a27a1bdabafbe290d1ff23eeb4659b07d554
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
The syntax now matches visibility's. This is less confusing than
before, we now have:
- targets like //foo, //foo:foo or //foo:bar
- same package match like //foo:__pkg__
- subpackages like //foo:__subpackages__
RELNOTES:none
PiperOrigin-RevId: 298598757
Change-Id: I6d02cf03c3c67d78998dda27a6529d53d0ef2708
This function is meant to be used for the tag containing exported_by.
RELNOTES:none
PiperOrigin-RevId: 298568236
Change-Id: Ia7b039d1764a3b79a3a0cc3f7f68a8eb17e6f0d5
Sunjay Bhatia