On Tue, Oct 22, 2024 at 13:50:26 +0200, Boris Kolpackov wrote:
> It wasn't clear to me from the paper whether this is meant to
> replace the JSON Compilation Database (compile_commands.json).
> There is some mentioning of it but I couldn't understand what
> it all means.

The mentions are mostly that compile_commands.json lacks both the fields
and structure to model modules compilation. I suspect compile commands
will still be *useful* for simple things like `clang-tidy` (when the
build is using a compatible `clang` compiler), but not if one is doing
things like `clang-tidy` on a `gcc` build (as `clang-tidy` would need to
discover how to make its own BMIs instead of the `gcc`-flavored BMIs the
build is going to use.

> In any case, if the answer is "yes" or even "sometimes", then
> I think this effort is overlooking headers. Recently I've learned
> that the compilation database is sometimes extended to include
> headers (what it means to have a compilation command for a header
> is usually unspecified). There is a long and still open issue
> for CMake on this:
>
> https://gitlab.kitware.com/cmake/cmake/-/issues/16285

Yes. Header units will be "easy" as they'll have actual build commands
associated with them. The issue with `#include`-only headers is that the
*consumer* is really dictating how it gets used (in the general case at
least): most headers don't really care up until someone does
`-Dclassname=other` (as a flag or `#define`) shenanigans. This revision
adds the "language" field to TU objects; we could certainly have
"c++header" as such a "language" for such things. I still don't know
what a command line would look like for such a thing though (e.g., in
CMake the include paths are `INTERFACE` for header-only libraries…which
wouldn't be given to the header itself if we generate a command line
"as-if" the target itself is consuming it). I suppose CMake could
generate some kind of "for include simulation purposes" and provide that
command as the header compile command (not unlike the
`VERIFY_HEADER_SETS` thing)…but that is getting into the weeds for now.

At this point, I'm mostly interested in getting enough groundwork laid
down so that tools can start understanding C++ module build graphs
enough to be able to start working with module-using projects. We have
compilers to a good enough state to play with and build systems can start
driving builds without tweezing things into the right order by hand; the
next step is to allow development workflows to start adopting modules
which means enabling non-compiler tooling to join the party. As long as
there is enough leeway for the representation of things like
include-headers in the future that's good enough for me for today.

Thanks,

--Ben