On Wed, Mar 06, 2019 at 16:48:45 +0200, Boris Kolpackov wrote:
> I was referring to the case where BMIs for header units are found via
> some sort of search path. Which is, it seems, where things are leaning
> towards with the idea of letting the compiler locate the BMIs and fall
> back to real headers if not found.

I think GCC fails if it can't find the BMI from the module mapper even
given the header itself. I really don't want to have implicit stuff
happening behind CMake's back when it thinks it is in control of such
things. That road leads to flaky builds and non-reproducible states
(usually) requiring debugging before figuring out that the build went
sideways and requiring a clean build to regain trust.

> But if direct, one-to-one mapping is supplied by the build system
> (as I believe it should be done), then, yes, an out-of-date BMI
> would indicate a build system problem.

This is the road I'm planning to go down for CMake. Clang/LLVM has
implicit stuff working with today's CMake because the compiler Just
Figures Things Out. As a build maintainer, I don't want to have to debug
compilers to figure out why some cache mechanism is giving incorrect or
outdated answers.

--Ben