Ben Boeckel <ben.boeckel_at_[hidden]> writes:

> This does not work in general. Just because you have the command line
> does not mean you understand which modules are allowed to be imported.
> Let's say you have a multi-config build (as CMake supports) where there
> are commands for release and debug. How is one supposed to understand
> which command is for which configuration and align them with consumers
> using the same configuration?

You write two separate databases, one for debug and one for release?
Maybe this is impossible/difficult in CMake, but not "generally".


> Also, tools like `clangd` that provide completion should not offer
> modules that are not importable from the TU in question. Yes, there
> exists module X in the build, but just knowing the command lines
> provides no indication that it lives in a library that *links to* the
> library the current TU is in, so doing autocompletion for it is counter
> productive.

The "consuming" TU's command line will include module references
(e.g., Clang's -fmodule-file options, MSVC's /reference, etc). From
that one should be able to determine which modules are visible to
each TU, no?