> On Mar 6, 2019, at 6:59 AM, Ben Boeckel <ben.boeckel_at_[hidden]> wrote:
>
>> 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.

+1.

>
>> 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.

It is the righteous one, IMO.

> 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
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&amp;data=02%7C01%7Cgdr%40microsoft.com%7Cc5821b03658945d5ab7d08d6a2445fe0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636874811898941487&amp;sdata=BdW8SXoi4ACxHXt2hKy8EZEwJXrCvnmiEvWcugDDoJo%3D&amp;reserved=0