Google Git Google Git
Sign in
bazel/rules_cc/refs/heads/main
commit
ff9c02369006867da978df11e38ef8fa993bf9ad
[log]
author
Luke Zarko <zarko@google.com>
Tue Nov 10 22:46:04 2026 -0800
committer
Copybara-Service <copybara-worker@google.com>
Tue Nov 10 22:46:44 2026 -0800
tree
2b080f077bef898c3ef8443ee2c1df0c0536675f
parent
f876b28ceac9b9068b8521e996ab3dfb58daf8d3 [diff] 
cc_common: expose `per_file_copts` to `create_compile_action` callers.

`cc_common.compile` adds the matching `--per_file_copt`s to the
`user_compile_flags` of the actions it creates (`get_copts`), but callers of
`cc_common.create_compile_action` build their compile variables themselves and
have no way to get them: `ctx.fragments.cpp` doesn't expose per-file copts, and
`cc_internal.per_file_copts` is gated to the rules_cc allowlist. So their
actions get different flags than the compiles of the same sources (b/582351896:
with header modules, Clang then rejects the `.pcm`s of the deps).

Add `cc_common.per_file_copts(cc_toolchain, source_file, label)`, gated by the
`create_compile_action` allowlist, so that those callers can add the flags to
their `user_compile_flags` like `compile` does.

This is one of the two placements proposed in b/582351896; the other was to
apply the flags inside `create_compile_action`.

Startblock:
  * // Put other blockers before this line to avoid churning.
  * has lgtm
  * is approved
  * and then
  * all comments are resolved
  * and then
  *[] allows unknown commit
PiperOrigin-RevId: 1018871920
Change-Id: I356b85441d772d5696ff360a094283b26d99b3da
1 file changed
tree: 2b080f077bef898c3ef8443ee2c1df0c0536675f
  1. .bazelci/
  2. .bcr/
  3. .github/
  4. cc/
  5. docs/
  6. examples/
  7. tests/
  8. .bazelignore
  9. .bazelrc
  10. .gitignore
  11. AUTHORS
  12. BUILD
  13. CONTRIBUTING.md
  14. googletest.patch
  15. ISSUE_TEMPLATE.md
  16. LICENSE
  17. local_bazel.bzl
  18. MODULE.bazel
  19. README.md
  20. WORKSPACE
  21. WORKSPACE.bzlmod
README.md

C++ rules for Bazel

  • Postsubmit Build status

This repository contains C, C++, and Objective-C language support for the Bazel build system.

For this module's main reference, see the Bazel documentation.

Get Started

Install Bazel

Follow the official instructions to Install Bazel.

Add rules_cc to your MODULE.bazel

Add the latest release to your MODULE.bazel project file.

Declare a build target

In a BUILD.bazel file, import and use the rules:

load("@rules_cc//cc:cc_binary.bzl", "cc_binary")

cc_binary(
    name = "hello_world",
    srcs = ["hello_world.cc"],
)

Build and run your project

Build and run your C/C++ binary with one command:

$ bazel run hello_world

To build the project without running the binary, use Bazel's build subcommand:

$ bazel build hello_world

Toolchains

Default autoconfigured toolchain

rules_cc includes an auto-configured toolchain that uses the local compiler installed on the host machine.

You can disable the autoconfigured C/C++ toolchain by adding the following Bazel flag to your project's .bazelrc file:

--repo_env=BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1

Hermetic toolchains

Configuring a hermetic toolchain makes your build more deterministic. rules_cc itself does not yet offer a hermetic toolchain distribution. Other community owned and maintained projects offer hermetic C/C++ toolchains:

Contributing

Bazel and rules_cc are the work of many contributors. We appreciate your help!

To contribute, please read the contribution guidelines: CONTRIBUTING.md.

Note that the rules_cc use the GitHub issue tracker for bug reports and feature requests only. For asking questions see: