C++ Logo


Advanced search

Re: [Tooling] [Ext] Modules and tooling: Resolving module import declarations

From: Jason Merrill <jason_at_[hidden]>
Date: Mon, 10 Sep 2018 12:04:47 +0100
On Mon, Sep 10, 2018 at 7:40 AM, Loïc Joly
<loic.actarus.joly_at_[hidden]> wrote:
> Le 08/09/2018 à 04:16, Tom Honermann a écrit :
>>> For closed-source library, it may not even be an option, but a
>>> requirement. And I expect some of those library writers might be very happy
>>> if they could avoid delivering headers, but only a collection of
>>> pre-compiled module interfaces for the compilers they support.
>> This is what I fear. If library providers were to do that, tools that are
>> unable to consume the provided module artifacts would be unable to parse any
>> source code that has a module interface dependency on those libraries.
>> Library providers that do this are not just restricting what compilers their
>> customers can use, they are restricting what tools their customers can use
>> on the customer's own code (at least the subset of it that has a module
>> interface dependency on the library). I would consider this a pretty user
>> hostile thing to do. I think we should make it as easy as possible for
>> library providers to enable their modular library to work with as wide a
>> range of tools as possible.
> What do you propose to do?
> I think closed-source library providers are happy to expose the interface of
> their code, but currently, in C++, headers contain many things related to
> implementation (private class members, template function bodies), and
> techniques to hide them have an impact on performance. So they provide the
> headers (or in some cases accept decreased performances/reduced features),
> but they would be very happy for a solution that allows them to avoid doing
> so. And I think delivering only compiled modules will have many attraction
> to them.
> I think the way for tools to help users of those libraries is not to hope
> those library writers will be kind enough to continue providing headers. The
> tools will need something (inside or outside of the standard) that can at
> least partially understand the binary module artefacts.

I think the way to help users is to not guarantee any level of
stability of the binary artifacts, so if a library wants to work with
multiple compiler versions they'll need to provide the source for the
module interface.


Received on 2018-09-10 13:05:09