bazel
/
rules_cc
mirror of https://github.com/bazelbuild/rules_cc
2
0
Fork 0
Code Issues Releases Activity
rules_cc/BUILD

26 lines
650 B
Python
Raw Permalink Normal View History

Remove defs.bzl usages BEGIN_PUBLIC Remove defs.bzl usages END_PUBLIC PiperOrigin-RevId: 693709660 Change-Id: I1c92999e23c153f865ad68ab802d907abaea74eb
2024-11-06 14:47:33 +00:00
load("//cc:cc_library.bzl", "cc_library")
Introduce flag --@rules_cc//:link_extra_libs 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
2023-02-16 12:14:43 +00:00
Automatic code cleanup. PiperOrigin-RevId: 509526713 Change-Id: I852b1620897d8c6787ca25b6790f245b5bc274f0
2023-02-14 15:49:18 +00:00
package(default_visibility = ["//visibility:public"])
Internal change PiperOrigin-RevId: 225221110
2018-12-12 19:24:00 +00:00
licenses(["notice"])
exports_files(["LICENSE"])
Introduce flag --@rules_cc//:link_extra_libs 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
2023-02-16 12:14:43 +00:00
cc_library(name = "empty_lib")
# Label flag for extra libraries to be linked into every binary.
# TODO(bazel-team): Support passing flag multiple times to build a list.
label_flag(
name = "link_extra_libs",
build_setting_default = ":empty_lib",
)
# The final extra library to be linked into every binary target. This collects
# the above flag, but may also include more libraries depending on config.
cc_library(
name = "link_extra_lib",
deps = [
":link_extra_libs",
],
)