mirror of
https://github.com/Kitware/CMake.git
synced 2025-10-23 18:08:31 +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
|
scanning results to infer ordering constraints, and tells the build tool
|
||||||
how to dynamically update the build graph.
|
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
|
Scanning Control
|
||||||
================
|
================
|
||||||
|
|
||||||
|
Reference in New Issue
Block a user