Not that CMake is zero-configuration, but it is possible (and, AFAIK,
being done today as noted by Boris). I even had tests for it back in
2019:

    https://github.com/mathstuf/cxx-modules-sandbox/blob/master/good-scanner/define.mpp

On Thu, Nov 02, 2023 at 22:02:35 -0700, Michael Spencer via SG15 wrote:
> 2.2. Caching Build Systems
>
> Another case where latency is particularly important is in caching
> build systems. Let’s assume the same collection of 100 TUs as
> before, but this time our build system can return cached results
> for compilations. In order to do this in a reproducable manner the
> cache key must be dependent on the the full input to each
> compilation, including all source files and modules it depends on,
> including how they are built, recursively.
>
> In a non-modules world this can be computed by minimal
> preprocessing; however, while resolving imports to module
> declarations is not needed for discovering direct dependencies, it
> is needed to determine the cache key for a compilation. Latency is
> important here because time spent discovering module declarations
> delays time to first byte for any cache hits.

Sounds fine to me.

> 3. Module Declaration Discovery
>
> Due to the structure of a preprocessing-file, the pp-module line is
> discoverable at the start of phase 4 of translation without
> processing any #includes or resolving any preprocessing
> conditionals. For some environments this can be done without a
> command line at all, or with only a partial one. The only thing
> preventing this is that the module-name and module-partition tokens
> may be subject to macro replacement.
>
> If this were not the case, then a reasonably simple parser can
> determine the module-name and module-partition of a source file
> without calling out to compiler specific tooling.

Agreed. I think this is the crux: scanners can be far simpler if they
can ignore (or partially implement) phases of compilation. This gives me
hope for other compiler frontends being able to use common tools (such
as `clang-scan-deps`) instead of needing `appleclang-scan-deps`,
`ibmclang-scan-deps`, `armclang-scan-deps`, etc. because there would be
fewer things that could interfere with accurate emulation of the actual
compiler's view of the source.

> 4. Compatibility
>
> This is a breaking change with C++20 and C++23, however, given the
> limited current deployment of modules and rarity of such use cases,
> the breakage is expected to be minimal.

I think it is reasonable if we can at least get warnings for such cases
placed into C++20 and C++23 modes. Bonus points for suggesting code
generation as a potential solution (even if just in the manpage for the
associated warning flag).

--Ben