*** Reason for rollback ***
Broke a test
*** Original change description ***
The auto-configured toolchains provided by Bazel itself have diverged heavily from the version maintained in this repo. There is no need to maintain this duplication until Starlarkification has progressed succiciently for rules_cc to be the source of truth for them.
This is particularly relevant for Bzlmod, which currently uses the toolchains defined in rules_cc. As a result, Bazel C++ builds will use subtly different toolchains depending on whether --enable_bzlmod is used or not. This is fixed...
***
PiperOrigin-RevId: 501228335
Change-Id: I858dc3ea44df7ae70b5603f6dc2e082b4540c42a
This is particularly relevant for Bzlmod, which currently uses the toolchains defined in rules_cc. As a result, Bazel C++ builds will use subtly different toolchains depending on whether --enable_bzlmod is used or not. This is fixed by loading toolchain detection logic from @bazel_tools in the module extension.
Closes #163
PiperOrigin-RevId: 501199523
Change-Id: I01f263d37495d0c5dd070c8a32945898d1d639c5
They are now part of the bazelbuild/bazel repository.
Copies buildifier changes contributed by Keith in https://github.com/bazelbuild/rules_cc/pull/128
RELNOTES:none
PiperOrigin-RevId: 435312636
Change-Id: I4d5d2f58d90026c0cdfb5c0a90709de7c28c6ccd
Default linker flags contains flags like -lstdc++ which should come after the
user libraries. The library flags are removed from default linker flags and added to link_libs instead which comes after user libraries.
See #9254
Incompatible flag bug: https://github.com/bazelbuild/bazel/issues/10905
I introduce a new method to repositories ctx that allows checking the value of a Starlark semantic option from a repository rule.
RELNOTES:none
PiperOrigin-RevId: 299336105
Change-Id: I81b9ee0c72e2a2252b406f1c584997389a530e40
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
*** Reason for rollback ***
Rolling back. No time before 1.0.
*** Original change description ***
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: 258756552
Change-Id: Ia44c0b5084ed9b28efbf9058e3dc29696db86fac
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: 258344117
Change-Id: I5c0ffb1c7b501facabb543ad57440ea067ab3d34
