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

Rene Rivera grafikrobot at gmail.com
Sat Sep 8 04:56:11 CEST 2018


On Fri, Sep 7, 2018 at 9:16 PM Tom Honermann <tom at honermann.net> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/tooling/attachments/20180907/4c88a53b/attachment.html 


More information about the Tooling mailing list