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
--//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
We use BUILD example added in previous CL and inspect the resulting *.so files with nm.
Also fixes implementation of shared library to work with Bazel after having flipped the legacy whole archive flag. This caused exported libraries to be dropped by the linker unless they were alwayslink.
Still more tests to come.
RELNOTES:none
PiperOrigin-RevId: 280640226
Change-Id: I34b48ce7379536352f87b703580083eb85ca67b3
This is only tested with Bazel at head. We modify the presubmits file so that we don't use release. The reason we don't use release is because we need very recent changes to Bazel to test cc_shared_library. In the future we will also test with release.
Also in following CLs, we will inspect in integration test the *.so output from these example builds to make sure that the correct symbols are linked statically and are visible.
After that we will add Starlark unit test to check error conditions.
RELNOTES:none
PiperOrigin-RevId: 280381939
Change-Id: I5de9b364a2a3db28d99558fbfca7bea8052e5114
Fixes:
* Enabled buildifier on the Bazel CI again
* Added Skydocs where missing
* Moved public files out of .../private/... (e.g. cc_toolchain_config_lib.bzl)
* Reformatted
* Removed unused loads
* Using relative labels for cc_configure related files
* Added development dependency on rules_proto
* they're not in the federation yet, so hand rolling in rules_cc's WORKSPACE file
* Added development dependency on rules_python (from federation)
* Cleaned up copybara (notable change - not using @rules_cc in labels inside rules_cc repo)
* Made cc_flags_supplier usable internally
* Moved load statements to the top of the bzl file
* Moved runfiles to the tools directory
* Unified toolchain_utils.bzl and find_cc_toolchain.bzl
RELNOTES: None.
PiperOrigin-RevId: 276479521
Change-Id: I3196896061fa2ee61a3efb130c214d288782066a
We now have copies of .bzl files that we have to keep in sync between @rules_cc and @bazel_tools/tools
I propose to re-enable the Buildifier presubmit once this issue is resolved.
*** Original change description ***
Run Buildifier as part of the presubmit.
As a result we will catch some errors already in GitHub, and not later in Critique when it's harder to fix them.
***
PiperOrigin-RevId: 265636234
Change-Id: I10730665134240b3f47950e0e8fa0add8e0bd591
As a result we will catch some errors already in GitHub, and not later in Critique when it's harder to fix them.
PiperOrigin-RevId: 262967050
Change-Id: If598cea7cf9283203bad94533a6bb5be3349e118
Googler