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
