On 09/07/2018 10:56 PM, Rene Rivera wrote:
> On Fri, Sep 7, 2018 at 9:16 PM Tom Honermann <tom_at_[hidden]
> <mailto: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.

I have no significant experience with game development. Is it typical
for such providers to restrict what editors their customers use to write
code that uses their library? Or to restrict what other tools their
header files can be consumed by (e.g., SWIG, static analyzers, etc...)?
I don't know, but I suspect restrictions like those are rare today.

Tom.