使用 Bazel 使用不同的编译器/链接器选项构建 C/C++ 依赖项答案

【问题标题】：Building C/C++ Dependencies with Different Compiler/Linker options with Bazel使用 Bazel 使用不同的编译器/链接器选项构建 C/C++ 依赖项
【发布时间】：2020-06-09 19:29:38
【问题描述】：

所以我正在修改一个项目以使用 clang++ 和 sanitizers（用于模糊测试）构建，而不仅仅是 g++。它使用 bazel 构建。

该项目当前下载了它的一些构建依赖项 (m4/bison/flex) 并使用 https://github.com/bazelbuild/rules_foreign_cc 中的 make_configure 规则构建这些依赖项。重要的是，这些仅用于代码生成，而不是链接/编译。

不幸的是，这些依赖项碰巧有各种消毒剂问题。这意味着如果我们使用 --copt="-fsanitize=address" 构建，我们就不能将它们用于代码生成并且构建失败！现在，如果我们遇到链接依赖项的敏感问题，那将是不可避免的，我们需要与维护人员一起解决问题，但现在我们真的更愿意解决这些问题，因为它们不像直接影响我们正在编译的实际目标的安全性和可靠性。

是否有一种简单的方法可以或多或少地指定“请忽略在命令行上仅针对此目标传递的编译器标志/链接器选项/等，并改用其他集合”作为规则？在大多数情况下，通过命令行（或通过全局配置）传递的 linkopts/copts/cxxopts 似乎是附加的，我们希望避免这种情况。如果没有，解决这个问题的最佳方法是什么？在包含实际构建规则的自定义规则中保存/取消设置/重置所有变量？

谢谢，埃弗里特

【问题讨论】：

提醒：对于 C++，您应该使用 g++，对于 C 语言，您应该使用 gcc。没有 C/C++ 语言。
是的，很公平。我们实际上使用的是 g++/clang++ 而不是 gcc/clang。我将编辑问题。

标签： c++ bazel

【解决方案1】：

所以，最终找到了我的答案。

这里有几种方法可能会奏效。一种是自定义 SkyLark 规则，它覆盖命令行提供的工具。与传递给编译器/链接器的某些选项相比，其他命令行选项可能无法很好地发挥作用，这确实具有更“面向未来”的潜在优势。

然而，最后更容易的是了解 gcc/clang 系列编译器有一个有趣的行为，可以很好地与 bazel 配合使用——如果你指定“冲突”的命令行参数，后面的似乎是总是采取。因此，我们所要做的就是确保将“-fno-sanitize=address”传递到我们想要关闭 ASAN 的目标的构建规则中，同时将“-fsanitize=address”传递到全局构建中。

希望这对遇到此类问题的其他人有所帮助。 --埃弗雷特

【讨论】：

【解决方案2】：

“正确的方法”是定义您自己的工具链并在其中添加一个功能，例如：

    asan_feature = feature(
        name = "address_sanitizer",
        enabled = True,
            flag_set(
                actions = all_compile_actions + all_link_actions,
                flag_groups = [
                    flag_group(flags = ["-fsanitize=address"]),
                ],
            ),
        ],
    )

您与features 一起传递给create_cc_toolchain_config_info()。

您可以为任何给定的工具链默认或不设置此功能enabled，您可以控制在CLI、每个package 和每个目标（例如cc_binary）上广泛使用的功能：

cc_binary(
    ...
    features = ["-address_sanitizer"],
)

明显的缺点是，涉及一些初步工作。

好处是，编译器配置/行为确实（应该）是工具链配置的功能，而不是每个目标都可以摆弄的东西。您将获得一个独立于任何给定工具链的特定编译器的抽象结构。

【讨论】：