As of Bazel 6.0.0, all Bazel-provided toolchains report consistent
compiler names that can be matched on with `select`. Having a central
place for `config_setting`s that can be used for this purpose makes it
so that rulesets don't have to define them themselves and moving the
compiler flag out of `@bazel_tools` becomes easier as it is no longer
referenced directly.
Also includes minor fixes to `//tests/...` so that it can be enabled in
CI.
Right now there should be no difference between `cc_host_toolchain_alias` and `cc_toolchain_alias` rules.
This is a potentially breaking change for Bazel, if something was depending on `current_cc_host_toolchain` try depending on `current_cc_toolchain` instead.
PiperOrigin-RevId: 528762965
Change-Id: Id2d211c61fa06a578a838c054682c3507aa48261
Remove redundant tags for copybara to replace labels with labels including the
repository, where there are no labels to substitute after 2f8c04c044.
PiperOrigin-RevId: 510103824
Change-Id: I9b65a6b7f9b48885aec4df5f4723273633be4860
Numerous tools override --custom_malloc to add debugging or monitoring runtimes
(see e.g. sanitizers). While this is fine for cases where the tool must also
override malloc to function, in other cases it's simply misuse of
--custom_malloc where no other mechanism exists to link an extra library.
This becomes especially problematic where a runtime library is supposed to be
added in certain configurations that should run in production or other
performance sensitive builds. In these cases, we should _not_ override malloc,
which may also be specified by a cc_binary target. Doing so would introduce
unwanted changes, potentially affecting performance negatively.
This is the @rules_cc counterpart to the equivalent Bazel tools flag
--@bazel_tools//tools/cpp:link_extra_libs. Users that use @rules_cc to build
their C++ projects may use both flags interchangably, however, the @rules_cc
flag should be preferred.
PiperOrigin-RevId: 510103352
Change-Id: Iafccd00ffdb65cb4f953d5acadc451cffc134533
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
buildbreaker2021