This makes it possible to remove dependency on protobuf. The dependency causes more problems than compatibility with some users of cc_proto_library from rules_cc.
Move WORKSPACE.bzlmod into correct directory.
PiperOrigin-RevId: 691445019
Change-Id: I45d7b4e381483de14ea2d20110be40f471a1ad12
BEGIN_PUBLIC
Fix the load broken by a new version of buildifier.
Apparently the native-cc lint has been split into native-cc and native-cc-proto. This meant that our native.cc_proto_library was getting incorrectly turned into cc_proto_library when copybara invoked buildifier.
END_PUBLIC
PiperOrigin-RevId: 622097522
Change-Id: Idb89a5f9facae20f490ac8f83a5adf2859cd52ab
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
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
Googler