[API Design][C++ Modules]: Source listings and interface properties

[ben.boeckel (Ben Boeckel (Kitware))]

@ruoso

I presume we also know how those nodes need to be parsed. Presuming the information for how to parsing the file is also available.

Yes, the scanning commands are statically known. There is the open question of Clang’s header units which apparently need to also care about the -D flags in the consumer when creating the BMI. However, I have zero idea of how to support that without also supporting dynamic nodes as well.

@ruoso

However, if that also means we don’t know the module name that is exported may require a full scan of all files in order to decide even where the modules are. If that’s the case, it’d be very unfortunate.

Yes. Again, a consequence of the Fortran-isomorphic module design. Luckily(?) with CMake’s target graph, you are limited in where you have to look (i.e., your own sources and PUBLIC sources in targets you depend on as well as their PUBLIC dependencies). I have test cases in the sandbox repo with the same module name in various places making sure that they get resolved in a way that makes sense for CMake at least (ignoring IFNDR situations it may be creating; I’m more interested in the build system behavior here).

@ruoso

I almost feel like I want CMake to require the files exporting interfaces to have a predictable name…

There are a number of folks that have expressed similar feelings. That discussion can probably be re-started once what happens after a filename’s last . is resolved .