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.

Bret

On Thu, Oct 31, 2024, 08:29 Steve Downey via SG15 <sg15_at_[hidden]>
wrote:

> I think we agree, though, that a deterministic dynamic set of files is in
> scope for any serious build system, and non-deterministic is out of scope
> and not something we need to worry about letting C++ do?
>
> That is, yes, you could do that, it just won't work, and that's user error
> not a problem with the facility? It's not a reason to not have the
> facility.
>
> Compile time io has other reasons to worry me. But not because of build
> systems.
>
> On Thu, Oct 31, 2024, 06:17 Boris Kolpackov <boris_at_[hidden]>
> wrote:
>
>> Steve Downey <sdowney_at_[hidden]> writes:
>>
>> > [...] but the description of dependency could be produced as a
>> > side-effect of compilation, and would not affect the shape of
>> > the graph.
>>
>> Unless the dependencies are auto-generated, right?
>>
>> You may disagree, but at this day and age I don't think you
>> can call a build system that cannot handle auto-generated
>> headers modern or general-purpose.
>>
>>
>> > a build system generator
>>
>> Not every build system is a meta-build system (and thus has a
>> a generator and all the problems and limitations stemming from
>> it). In fact, if you look at modern build systems (Bazel, Buck2,
>> build2), none of them are meta-build systems.
>>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>