Commit Graph

10 Commits

Author SHA1 Message Date
Googler 4de26b53a6 Remove need for exported_by or linked_statically_by
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
2020-02-12 08:01:50 -08:00
Googler 262ebec3c2 Fix buildifier warnings in @rules_cc
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
2019-10-24 07:01:25 -07:00
Googler 4a1c578fb0 C++: Move tools/cpp from bazel_tools to rules_cc
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
2019-08-21 07:30:04 -07:00
Googler b7fe9697c0 C++: Add two more rules to defs.bzl in rules_cc
These rules are in bazel_tools.

RELNOTES:none
PiperOrigin-RevId: 259298756
Change-Id: I9ed4b8f3cd712adc889a950765c96b5b68a5d43c
2019-07-22 04:17:22 -07:00
Googler d36c8d400c Refactor rules_cc to follow https://docs.bazel.build/versions/master/skylark/deploying.html
RELNOTES: None.
PiperOrigin-RevId: 253736769
Change-Id: Ib13ecb077559f890aa3cc207b7ec1a53ac18d553
2019-06-18 00:21:44 -07:00
Marcel Hlopko 6cd7e75fc4 Update examples for platforms 2019-05-24 14:52:19 +02:00
Googler eeec015f3e Update rules_cc for --incompatible_enable_cc_toolchain_resolution
[Copybara import of https://github.com/bazelbuild/rules_cc/pull/14]

https://github.com/bazelbuild/bazel/issues/7260
Merge 3e6d3b9a4a into b308aae57f

PiperOrigin-RevId: 248296402
2019-05-15 02:19:39 -07:00
hlopko b308aae57f Add ctx argument to cc_common.configure_features
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
2019-05-08 01:46:21 -07:00
Googler 2d3bc12294 Remove duplication of feature_configuration
RELNOTES: None.
PiperOrigin-RevId: 236652129
2019-03-04 07:53:44 -08:00
hlopko 3d5980e5cb Add example writing custom rule that depends and is dependable from rules_cc
RELNOTES: None.
PiperOrigin-RevId: 235869541
2019-02-27 00:37:05 -08:00