On Tue, 12 Feb 2019 at 21:52 Ben Boeckel <ben.boeckel_at_[hidden]> wrote:

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


I was talking of encoding the module name in the filename of the interface
header unit file.
Let's not maintain unmaintainable files by hand :)


>
> --Ben
>