C++ Logo

sg15

Advanced search

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

From: Tom Honermann <tom_at_[hidden]>
Date: Mon, 10 Sep 2018 11:48:26 -0400
On 09/10/2018 07:04 AM, Jason Merrill wrote:
> 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.

Sounds good to me :)

Tom.

Received on 2018-09-10 17:48:36