mirror of
https://github.com/Kitware/CMake.git
synced 2025-10-23 09:37:51 +08:00
Help/cmake-cxxmodules: describe the compilation strategy
This commit is contained in:
@@ -12,6 +12,49 @@ to scan source files for module dependencies during the build, collates
|
||||
scanning results to infer ordering constraints, and tells the build tool
|
||||
how to dynamically update the build graph.
|
||||
|
||||
Compilation Strategy
|
||||
====================
|
||||
|
||||
With C++ modules, compiling a set of C++ sources is no longer embarrassingly
|
||||
parallel. That is, any given source may first require the compilation of
|
||||
another source file first in order to provide a "CMI" (compiled module
|
||||
interface) or "BMI" (binary module interface) that C++ compilers use to
|
||||
satisfy ``import`` statements in other sources. With headers, sources could
|
||||
share their declarations so that any consumers could compile independently.
|
||||
With modules, declarations are now generated into these BMI files by the
|
||||
compiler during compilation based on the contents of the source file and its
|
||||
``export`` statements.
|
||||
|
||||
The order necessary for compilation requires build-time resolution of the
|
||||
ordering because the order is controlled by the contents of the sources. This
|
||||
means that the ordering needs extracted from the source during the build to
|
||||
avoid regenerating the build graph via a configure and generate phase for
|
||||
every source change to get a correct build.
|
||||
|
||||
The general strategy is to use a "scanner" to extract the ordering dependency
|
||||
information and update the build graph with new edges between existing edges
|
||||
by taking the per-source scan results (represented by `P1689R5`_ files) and
|
||||
"collating" the dependencies within a target and to modules produced by
|
||||
targets visible to the target. The primary task is to generate "module map"
|
||||
files to pass to each compile rule with the paths to the BMIs needed to
|
||||
satisfy ``import`` statements. The collator also has tasks to use the
|
||||
build-time information to fill out information including ``install`` rules for
|
||||
the module interface units, their BMIs, and properties for any exported
|
||||
targets with C++ modules.
|
||||
|
||||
.. _`P1689R5`: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1689r5.html
|
||||
|
||||
.. note:
|
||||
|
||||
CMake is focusing on correct builds before looking at performance
|
||||
improvements. There are known tactics within the chosen strategy which may
|
||||
offer build performance improvements. However, they are being deferred
|
||||
until we have a working model against which to compare them. It is also
|
||||
important to note that a tactic useful in one situation (e.g., clean
|
||||
builds) may not be performant in a different situation (e.g., incremental
|
||||
builds). Finding a balance and offering controls to select the tactics is
|
||||
future work.
|
||||
|
||||
Scanning Control
|
||||
================
|
||||
|
||||
|
Reference in New Issue
Block a user