Em sex., 26 de mai. de 2023 às 11:57, Mathias Stearn <
redbeard0531+isocpp_at_[hidden]> escreveu:

> Sorry, there was a detail that I forgot to mention explicitly that is
> important to understanding how this answers your questions. The key is that
> this leans *very* heavily on ninja's restat=1 reature and a write_if_changed
> function
> <https://github.com/RedBeard0531/cxx_modules_builder/blob/e13174805992c7aa10e8fbc9b1452cbfc0f66ecc/modules_builder.py#L92-L99> in
> the scanner to be sure to only touch files if their contents change. This
> means that even if we need to redo a scan (which we would because all scans
> depend on the yaml file holding the list of importable headers), we *don't*
> need to recompile unless it actually would affect that compile.
>

This is a massive change in requirements for build systems.

Either the tool driving the build supports the `restat` feature (as ninja
does), or the build system has to use the checksum of the contents to drive
target invalidation (as scons does).

It probably means that we need the compiler to support an option to
only overwrite the file if the contents are different. The alternative
being that the build rule has to generate an intermediate file which then
only gets renamed over the old one if the contents are not the same.

It essentially means that `make` is no longer a viable implementation to
drive a C++ build (not even generated make, as CMake does). As I mentioned
before, we use ninja for development builds, but it doesn't satisfy all our
requirements for the production builds (e.g.:
https://github.com/ninja-build/ninja/issues/1139 ).

And that's the crux of what the paper is pointing at: Only a subset of
build systems in use today will be able to viably support Importable
Headers, which will exclude systems where Named Modules could be
implemented.

I guess the fundamental question is whether we have consensus on "GNU Make
is no longer a viable C++ build driver". I, personally, strongly oppose
that direction.

daniel