C++ Logo

sg15

Advanced search

Re: [Tooling] [isocpp-lib-ext] [Ext] Modules and tooling: Resolving module import declarations

From: Rene Rivera <grafikrobot_at_[hidden]>
Date: Fri, 7 Sep 2018 21:56:11 -0500
On Fri, Sep 7, 2018 at 9:16 PM Tom Honermann <tom_at_[hidden]> wrote:

> On 09/07/2018 06:38 PM, Loïc Joly wrote:
> >
> > 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.
>

Such library providers tend to be perfectly happy to only support certain
tools for the libraries they distribute. Yes, it does restrict what users
can do. But that's not usually a problem for their audience. The common
case is where it's a closed platform with a single set of, usually
proprietary, tools for it. For example in console game development.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net

Received on 2018-09-08 04:56:24