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
Add an explicit export statement (with the same visibility) for
files that are currently only implicitly exported and used by other
pacakges. This prepares changing the visibility of implicitly-exported
files to be package private without causing a breakage.
PiperOrigin-RevId: 280171386
Change-Id: I083a9d4f82067b4d4c94d7b554013aeb91e401cc
We're working on removing C++ toolchain autoconfiguration logic out of Bazel,
and moving towards using rules_cc repository for it. Some bzl files will no
longer be available through bazel/tools/cpp/*, but through
@rules_cc/cc/*.
RELNOTES: None.
PiperOrigin-RevId: 279935457
Change-Id: I3bae259548dacc5c6789efe0f27dd07738c1057c
Labels in toolchains attribute need to include the repository, otherwise the resolution won't work.
RELNOTES: None.
PiperOrigin-RevId: 279347045
Change-Id: Iba1eb8bb677771e2c089ab6bc1b5e019c4da434e
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
This commit allows the creation of distributions, with 0.0.1 being the first version.
See distro/README.md for details on how to build a release.
This commit also uses a new version of the Bazel federation that contains rules_pkg 0.2.2 instead of 0.2.1.
There are still some problems with the WORKSPACE stanza that is being printed by the release notes generation script, though:
- It references a //cc:deps.bzl file, which doesn't exist. I have to modify the scripts in rules_pkg to support a flag like 'has_deps'.
- It doesn't support the Bazel federation yet, since it always tells users to download code from the rules_cc repository.
BEGIN_PUBLIC
Remove unused load statements from .bzl files
After transitive loads have been disabled in Blaze, unused load statements have
no effect (besides not useful memory consumption).
The CL has been created automatically by calling `buildifier --lint=fix --warnings=load` on all .bzl files.
The following additional command were run on all affected files to clean them up:
* buildifier -a -v --lint=fix --warnings=load-on-top
Moves all load statements to the top of a file
* buildifier -a -v --lint=fix --warnings=same-origin-load
Compresses all load statements from the same .bzl file to one load statement
END_PUBLIC
PiperOrigin-RevId: 269552258
Change-Id: I85ae6bf3467bf560ac3e0ab2470f864abb89e8e6
Usage: CC=clang bazel build //foo:bar --features=thin_lto -c opt
RELNOTES: Bazel now supports ThinLTO builds on Linux for Clang versions >= 6.0. ThinLTO can be enabled through --features=thin_lto
PiperOrigin-RevId: 265649618
Change-Id: I68a38b8b8c1480e3b73d8e6f24e9dafece2c7de6
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
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
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
With CROSSTOOL not existing anymore, the comparison script can continue being useful in refactoring Starlark toolchain config rules.
RELNOTES: None.
PiperOrigin-RevId: 262544859
Change-Id: I633fdc4c09c7643d6e5d1c10537efa3c9a82003c
We don't need to select a toolchain by the identifier when we get the proto from Starlark rules because in that case the proto contains a single toolchain.
The difference in toolchain_identifier field between the first and the second proto file will be caught as any other field.
RELNOTES: None.
PiperOrigin-RevId: 262543753
Change-Id: I1e66ee302bf551ade883c217f6269f44382393c0
Googler