The cc_shared_library_permissions mechanism was introduced to add control over
which cc_shared_libraries can export a given cc_library. If the repo is big
enough, the owner of a cc_library might want to prevent someone else in a
different package making their library part of the ABI of a public shared
library because that makes it harder to change the cc_library. This does not
apply accross repositories because a dependant repository can overwrite
anything from a repository dependency anyway.
However, it is becoming more apparent than even though this mechanism should
exist, it should not be enabled by default since most people don't need it. To
enable it pass the flag --//examples:enable_permissions_check=True.
RELNOTES:none
PiperOrigin-RevId: 363171677
Change-Id: I8afb3294806bb3053ee1279c6e9c5355089bccbb
Adds test for fix to cc_binary in a previous CL which required a Bazel change.
RELNOTES:none
PiperOrigin-RevId: 361152661
Change-Id: Ic7b9cda6636eff6bc231f00f8cdd542e0c88113c
- 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
Googler