On Thu, 31 Oct 2024 at 15:30, Bret Brown via SG15 <sg15_at_[hidden]> wrote:
>
> I think it's safe to say that C++ generating source files in any language is a novel enough feature to deserve a thorough paper and a full review. I don't know that we need to hash out that possibility in detail much here unless someone is authoring papers in that direction and wants early feedback.
>
> That being said, anyone interested in that direction should consider reviewing the P1689 and associated Tooling Study Group (SG-15) minutes. SG-15 polled very favorably on that paper and it has been implemented in three major platforms for good reasons. And those reasons include the fact that a significant part of the ecosystem does not operate well unless it knows upfront the nodes in a build graph (i.e. translation units) and what order they need to be built in. If C++ modules do not exist yet, they cannot be scanned, and it would not be generally possible to know whether building a valid C++ translation unit would need to be done by a particular point in the build graph.
>
> To be more concrete , consider a C++ source file with an `import generated_module;`. The translation unit or units that generate that module would need to be built before the *dependency scanner* (e.g. clang-scan-deps) executes so that the build system system already has a Built Module Interface prepared for `generated_module`.
>
> But how does the build system know what build step generates that module source code so that the relevant BMI can be prepared before the relevant import statement is encountered? This is an interesting question to me. I can come up with ideas, but some interesting ones would justify language changes (like a C++ statement that declares I/O intentions that is accessible to dependency scanning tools).
>
> Some build systems could just pause a build job and block until relevant nodes or edges in the build graph are filled in. But this is a problem for popular build systems like ninja. It is also a problem for distributed build systems that need to know which files to move into a remote environment before building there.

I don't think it's all that novel to have C++ generate source files.
That's really just a code generator like the ones we have had to deal
with before,
albeit one that runs in an interesting context, instead of a good old
runtime generator that just runs and generates code.

But that also doesn't necessarily mean dynamic build graph nodes. I'm
not a build system expert, but I do know how to construct my (CMake)
builds
so that the generative build is done before the builds that need its
results, so that the generation results are there when the next step
is configured as part of an overall build (the build, not the
configure-step of the overall build), and it then feeds Ninja a
perfectly static build graph. It's not necessarily so that every level
of all nested builds is an all-static graph, but nevertheless the
concerns about an actual build tool not liking dynamically-added build
graph nodes
are surmountable.