On Thu, Oct 24, 2024 at 19:16:18 -0700, Herb Sutter via SG15 wrote:
> So that no good deed goes unpunished 😊 I'll warn you that I intend to
> be greedy: Some of us will be asking for general compile-time I/O, or
> at least O (output), in a consteval function. For example, to create a
> file that contains:

Nifty. Not easy though. Maybe if we had a build monoculture this could
be specified and implemented uniformly, but there is a *very* narrow
hole that one can thread through the umpteen build systems in use for
common semantics and supportability of such a feature. Building modules
is likely to leave a lot of the "just glob things"-level build systems
in the dust, but there are a lot of systems that are slightly more
sophisticated that can probably limp along with some rudimentary
"modulename == some_func(filename)" non-P1689-ish level of support.

Re-ordering your specific wishlist items a bit:

> * JSON
> * even binary output files (e.g., .winmd files needed to describe
> C++ types to the Windows WinRT subsystem, a necessary thing for
> reflection+generation to replace special/extended compilers needed to
> generate that for C++ types today)

In general, this would work if the files that would be written to were
reported in the P1689 format during scanning. If consteval were
performed by scanners (essentially relegating it to full-compiler-only
kinds of things for actual builds rather than just "make modules work")
We'd likely need a new classification ("additional-outputs" or
something), but that is minor. The collation mechanism could then add
the appropriate flags to place them in the right directory and also use
it to hook up consumption with something expecting such files. I think
there would need to be some "labeling" other than filename (with
uniqueness constraints like a module name) to know what consumer gets
which file from the variety of producers. Just a filepath could work if
it is purely a side effect (and not expected to be used as an input,
implicit or explicit, anywhere else in the build graph).

Honestly, it's probably more practical to just reflect-codegen some
printf statements and execute it to write to a file the build system
explicitly knows about than to have it as part of compilation itself.

> * C++ code
> * another language’s code, such as to generate an FFI binding to
> call the C++ source (e.g., to emit a .java file that defines a Java
> `interface` that can be bound to a C++ type)

Generally you would also need to generate JNI bindings and compile them
with a C++ compiler to make the Java source actually talk to the code as
well. Very few tools support compiling dynamically generated C++ code
without something like a generated "include all of the sources" unity
compilation mechanism.

Unanswered that are missing for such generated code (from a CMake point
of view, but these questions have rhymes in practically every build
system I know of):

- Does this generated code need to use other libraries than the TU that
  generated it? For example…linking the JNI libraries that the generator
  is unlikely to do.
- Once it gets compiled…what is it being linked into? While `llbuild`
  can apparently generate compilation nodes during the build, I would be
  very surprised if it was comfortable making *linking* nodes from thin
  air.
- Once it gets linked itself…what else needs this thing? Probably some
  shared object to be loaded at runtime if it is bindings. How do we
  know what wants it.

While such compiled code generation can be *done*, it has very deep
connections with the build system itself beyond "I'm going to write some
C++ code to a path".

> Of course, all the usual security controls would need to apply, like
> sandboxing and controlling what directories can be written to.

Compiler flags can manage this and the collator can manage it.
Distributed builds will *really* want to be able to scan for what
outputs would be made so that they can know what files to ship back to
the coordinator for further distribution as necessary.

Thanks,

--Ben