BEGIN_PUBLIC
Copybara import of the project:
--
56e69b82484f1a9fb55d8173cc112f9f608f3581 by Fabian Meumertzheim <fabian@meumertzhe.im>:
Simplify WORKSPACE setup and update ancient deps
By removing a single unused `bzl_library` target, rules_cc no longer has
any dependencies that would need to be loaded by a dependency macro. The
existing macro is made a no-op.
The few needed Bazel Federation dependencies are inlined and, in the
case of bazel_skylib and abseil-py, updated to modern versions.
Also reorders `WORKSPACE` to list direct dependencies first and keeps
`MODULE.bazel` in sync with the dependency versions used in WORKSPACE.
The `ubuntu1604` CI pipeline is removed as the version of Python used by
it is no longer supported and the distribution is EOL. Instead, a new
pipeline is added to check the Bzlmod build.
END_PUBLIC
COPYBARA_INTEGRATE_REVIEW=https://github.com/bazelbuild/rules_cc/pull/165 from fmeum:fix-workspace-module 56e69b82484f1a9fb55d8173cc112f9f608f3581
PiperOrigin-RevId: 501245864
Change-Id: Ib71ad910705807a00929a76774387a38d2da0f9f
*** 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
The version has never been updated since the first release and since rules_cc is currently a slim wrapper around Bazel-provided rules, version detection shouldn't be necessary.
Instead, add an alias to the Bazel-provided runfiles library under //cc/runfiles, following https://bazel.build/rules/deploying.
Closes #162
PiperOrigin-RevId: 500929486
Change-Id: I3290c2b836af2313fbf45459c81af24fbde877d0
- point to bazelbuild/platforms for @platforms
- Use a newer version of rules_go for our internal rules.
- Make a bzl file used in a test visible to the tests.
I believe this fixes a build breakage in bazel at head and 5.3.0
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
1. Add a repeated Configuration field to CqueryResult, and fill in the
checksum, platform, and mnemonic fields.
2. Add a configuration_id field to ConfiguredTarget, and deprecate the existing
configuration field in ConfiguredTarget. The configuration_id field is an index
that points to the Configuration message stored in CqueryResult, following the
same pattern as ActionGraphContainer. This avoids duplicating the same
Configuration message for each ConfiguredTarget.
RELNOTES: Include more information about configurations in cquery proto
formatted output. This deprecates the configuration field of
AnalysisProtosV2.ConfiguredTarget, and adds a new field, configuration_id, to
be used instead.
PiperOrigin-RevId: 429129916
Change-Id: Id048229a6872e6462b67cfe3041cdc907967d7bf
Adds back providers to cc_shared_library bzl file in rules_cc until TF is using
bazel from head and can use the builtin cc_shared_library version.
RELNOTES:none
PiperOrigin-RevId: 409136047
Change-Id: I53388c18bcbc555e8a3c7edbc5e54634375f051f
Fabian Meumertzheim