On Tue, Feb 12, 2019 at 21:28:50 +0100, Corentin wrote:
> Similarly vcpkg and ports are, very sanely, source-based.
> They wouldn't function differently than today.

I think they have the same issue as Linux distributions, but may have
better or more easily available optimization opportunities via BMIs.

They still do "build A, install A, build B, install B" steps (optionally
with "remove build tree" after each install). If B can't consume A
without A's build tree still laying around… There's also nothing
stopping B from using a different compiler than A today. Hooking up C++
together through BMIs exclusively (rather than as an optimization)
breaks things or ends up duplicating work for a GCC-built stack and a
Clang-built stack of packages. Nevermind what's supposed to happen when
you want to link together two projects which don't have an intersection
of supported compilers.

> * Reason 47 to have a deterministic mapping from module name to Module
> Interface Units identifier.

If this is how the build tools decide what to do with external modules,
so be it. But, I'm fine with it being a format output as the result of a
build that compilers or build tools can generate (like a .so or .dll)
and consumed via CMake's usage requirements or extracted from special
values in .pc files. I certainly don't want to be required to write or
maintain such a thing by hand.

--Ben