C++ Logo


Advanced search

Re: [Tooling] Modules feedback

From: Corentin <corentin.jabot_at_[hidden]>
Date: Tue, 12 Feb 2019 23:05:47 +0100
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

Received on 2019-02-12 23:06:01