| commit | 5c3e987e81a1331714014fc133664e1f7a7582f9 | [log] [tgz] |
|---|---|---|
| author | PikachuHy <pikachuhy@linux.alibaba.com> | Fri Oct 31 13:23:24 2025 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Fri Oct 31 13:23:52 2025 -0700 |
| tree | ae553af72bd328792f2fee25fe37745c4f97532a | |
| parent | 9b9efedf1838a4d87dc312956e19ba0b9b326fe2 [diff] |
[4/5] support C++20 Modules, support one phase compilation I split the XXL PR https://github.com/bazelbuild/bazel/pull/19940 into several small patches. This is the fourth patch of Support C++20 Modules, which supports one phase compilation. ## Changes of build graph First, files are scanned, resulting in the creation of `.ddi` files. If the compiler being used is Clang, the tool `clang-scan-deps` is employed. Next, the generated `.ddi` files are aggregated into a `.CXXModules.json` file using the `aggregate-ddi` tool. Following this, the `.CXXModules.json` file, along with the `.ddi` files, is used to generate `.modmap` files through the `generate-modmap` tool. Finally, the source files are compiled into object files. If a file is a module interface, a corresponding module file is produced as a byproduct. The following diagram illustrates the scanning process. ``` ┌────────┐ ┌────────┐ ┌────────┐ │foo.cppm│ │bar.cppm│ │main.cc │ └────┬───┘ └────┬───┘ └────┬───┘ │ c++-module-deps-scanning │ │ │ │ │ ┌────▼───┐ ┌────▼───┐ ┌────▼───┐ │foo.ddi │ │bar.ddi │ │main.ddi│ └────┬───┘ └────┬───┘ └────┬───┘ │ │ │ └───────────────────────────┼───────────────────────────┘ │aggregate-ddi ┌────────▼───────────┐ │demo.CXXModules.json│ └────────────────────┘ ``` The following diagram illustrates the compile process of `foo.cppm`. ``` ┌────────────────────┐ │demo.CXXModules.json│ └─────┬──────────────┘ │ │ ┌───────┐ │ ┌───────────┐ ┌─►│foo.ddi├─────────┤ │ bar.cppm │ │ └───────┘ │ └─────┬─────┘ │ │ │ │ │ │ │ │ │ c++-module-deps-scanning │ │ │ ┌────────┐ │ ┌───────┐ ┌─────▼────┐ ┌────▼─────┐ │foo.cppm├─────────────────────┴─►│foo.d │ │foo.modmap│ │ bar.pcm │ └───┬────┘ └──┬────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ │ │◄───────────────────────────────┴─────────────┴─────────────────┘ │ c++20-module-compile ┌────────▼─────────┐ │ foo.pcm && foo.o │ └──────────────────┘ ``` ## Changes of compile I modified the CppCompileAction to include the relevant context, inputs, and outputs. Context: Module files and `.CXXModules.json` files Inputs: Module files, `.modmap` file, and `.modmap.input` file Outputs: Module files and `.CXXModules.json` files The primary difference in CppCompileAction is the addition of the `computeUsedCpp20Modules` function. The restart mechanism is utilized; if the necessary C++20 Modules files are not ready during compilation, the current compilation will exit and wait for an appropriate time to recompile. Closes #22553. PiperOrigin-RevId: 826606472 Change-Id: I7548ebfbf71a1faaa5d08317429a1e77e2454b54
This repository contains a Starlark implementation of C++ rules in Bazel.
The rules are being incrementally converted from their native implementations in the Bazel source tree.
For the list of C++ rules, see the Bazel documentation.
Add the following to your WORKSPACE file:
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") http_archive( name = "rules_cc", urls = ["https://github.com/bazelbuild/rules_cc/archive/refs/tags/<VERSION>.tar.gz"], sha256 = "...", )
Then, in your BUILD files, import and use the rules:
load("@rules_cc//cc:defs.bzl", "cc_library") cc_library( ... )
This repo contains an auto-detecting toolchain that expects to find tools installed on your host machine. This is non-hermetic, and may have varying behaviors depending on the versions of tools found.
There are third-party contributed hermetic toolchains you may want to investigate:
If you'd like to use the cc toolchain defined in this repo, add this to your WORKSPACE after you include rules_cc:
load("@rules_cc//cc:repositories.bzl", "rules_cc_dependencies", "rules_cc_toolchains") rules_cc_dependencies() rules_cc_toolchains()
This repository also contains migration tools that can be used to migrate your project for Bazel incompatible changes.
Script that migrates legacy crosstool fields into features (incompatible flag, tracking issue).
TLDR:
bazel run @rules_cc//tools/migration:legacy_fields_migrator -- \ --input=my_toolchain/CROSSTOOL \ --inline
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:
rules_cc mailing list#cc on slack.bazel.build