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.
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
When adding tags to a native cc_library rule that is created through a macro we
were not properly considering the case where the tags came from a different
file and therefore were frozen. This caused an error.
RELNOTES:none
PiperOrigin-RevId: 283039855
Change-Id: Id4cb45675a08ca65196f4f7771abdd5bb0705b79
Googler