--//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
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
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
Libraries are tagged with LINKABLE_MORE_THAN_ONCE can be linked into more than
one shared library and not give an error.
RELNOTES:none
PiperOrigin-RevId: 297352891
Change-Id: Id32b5c341bfd9d5906d67216773e82b0d8b63faf
The --experimental_cc_shared_library used to block API methods
that were needed in the cc_shared_library implementation. However, these
methods have been made freely available to everyone so that people can start
migrating to the new API.
With that change, the cc_shared_library has become free to use unless we block
it with the method call added in this CL.
RELNOTES:none
PiperOrigin-RevId: 297127873
Change-Id: I103fe7724b9c4956a5bee8bed0f6d074a6e453f1
The same command line can be obtained with the attributes
user_link_flags and additional_linker_inputs used together.
In the first design iterations of cc_shared_library it was decided to have the
visibility_file attribute so that a cc_shared_library could be used for many
different platforms smoothly.
For this to work the visibility file would have had to be platform neutral and
then Bazel would have had to write a visibility file specific for each
platform, e.g. the version script for Unix and the exports map for Windows.
However, in the last approved design it was decided not to have Bazel get in
the business of understanding symbols and automatically writing export maps.
With this approach, it then became necessary for people to use selects() in the
visibility_file attribute depending on the platform that the file was for.
Since we have added a new way to add files with the attribute
additional_linker_inputs and we need selects() anyway,
it doesn't make sense to keep the visibility_file attribute, the
same can be achieved with selects in the other two attributes mentioned.
In any case, if this can be made more ergonomic in the future, we can do so.
However, removing this attribute after flipping the experimental flag would be
an incompatible change.
PiperOrigin-RevId: 295925566
Change-Id: I52733e006f4b0f79f50380e89fc2eeae58dbad4d
Before dynamic lib dependencies of cc_shared_library were always linked at the
end. Now for creating the command line we respect the topological order that
would be given when getting the libs from the dependency graph created by the
cc_libraries.
RELNOTES:none
PiperOrigin-RevId: 295676824
Change-Id: I327a0e10920f18fed234dd5835e54cab75a0d428
Any library should be exportable by any cc_shared_library target regardless of whether the cc_shared_library target is in the same package or a parent package as long as the library author gives permission.
The library author can now do this by writing tags=["exported_by=//foo,//baz"].
PiperOrigin-RevId: 295137965
Change-Id: I4acffd26981fedd6cb0c505e2691da0c70a7b6b0
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
This is in preparation to renaming linked_statically_by to exported_by. The attribute linked_statically_by became redundant in a previous CL that added the static_deps attribute and made libraries in exports be linked statically automatically.
RELNOTES:none
PiperOrigin-RevId: 293355106
Change-Id: Iac987087e2f8e280f0fcaa2b7fcf61c55542825b
This removes the need for linked_statically_by, although both attributes work for now. The attribute linked_statically_by will disappear from cc_library and instead we will add exported_by which will allow library authors to retain the power of deciding who exports their library.
When a library is linked statically by more than one shared library and this library was only supposed to be linked once, i.e. it contains static initializers, then Bazel will give an error.
PiperOrigin-RevId: 293319906
Change-Id: I3713511e09feffb9429d38ac3ae868498ed4afe6
linked_statically_by attribute in cc_library will have a nodep label type
instead of a string type.
RELNOTES:none
PiperOrigin-RevId: 289665470
Change-Id: Ic86f3cd0fecf1ad8befb21844c0d7176dc898934
Order of libraries should be topological sort when constructing depset for
LinkingContext.
Also remove condition that failed when it shouldn't with a valid combination of
libraries.
RELNOTES:none
PiperOrigin-RevId: 282943411
Change-Id: I0b727c4cdeaf484e1c4177a714542eae7f167613
We need @rules_cc in front of the toolchain type in cc_shared_library. This is
still experimental.
More complete test suite is on the way in a separate CL I'm working on.
RELNOTES:none
PiperOrigin-RevId: 282716323
Change-Id: I797ef08f18987adef82b7c7d484e2838f4e1ba6a
It used to propagate TransitiveInfoCollections for exports which is not ideal.
RELNOTES:none
PiperOrigin-RevId: 281056556
Change-Id: I2ec39292aefb55369720fbbb93ee1e2f8704b8db
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
Here we are duplicating bazel_tools/tools/cpp. The goal is for the BUILD files in bazel_tools/tools/cpp to have an alias that point to rules_cc. Then later on with the incompatible flag these aliases will no longer be valid.
Working towards #8743
RELNOTES:none
PiperOrigin-RevId: 264604076
Change-Id: I389702793a1a95b0990dce93577de2b7182e2e6b
In order to migrate C++ rules to platforms, we need the access to the C++
configuration fragment in Starlark APIs. All existing APIs have already access
to it, but cc_common.configure_features doesn't. This change adds a
ctx argument to configure_features.
This is the migration needed for
https://github.com/bazelbuild/bazel/issues/7793, and is part of the effort for
https://github.com/bazelbuild/bazel/issues/6516.
If the rule doesn't depend on cpp fragment yet, you will have to add `fragments
=['cpp']` argument to the rule() call.
Note that this behavior is only available in Bazel 0.25 (to be released this month).
RELNOTES: None.
PiperOrigin-RevId: 247171967
This will make sure the copybara export is reversible, which is needed for setting up copybara workflow for importing github PRs.
RELNOTES: None.
PiperOrigin-RevId: 238445502
