On 09/07/2018 06:38 PM, Loïc Joly wrote:
> Le 02/09/2018 à 17:16, Tom Honermann a écrit :
>>
>> The example is meant to reflect the scenario where a project (t.cpp)
>> uses a packaged component (foo). Assuming that module artifact
>> formats remain non-portable across compilers and non-stable across
>> compiler releases, it doesn't make sense for a package manager to
>> install module artifacts.
>
> Could you develop that?
>
> Currently, libraries are non portable across compilers and non-stable
> across compiler releases, but package managers still allow to install
> pre-compiled libraries. They just need to be able to handle a
> collection of versions. So am I missing something?

Some compilers strive for cross-compiler ABI compatibility and have a
good track record of maintaining ABI compatibility across versions. For
example, Gcc and Clang both implement the Itanium ABI and Clang is
making good progress towards ABI compatibility with the Microsoft
compiler. But the maintainers of these compilers are not currently
working towards compatible module artifact formats.

Regardless, this is orthogonal to the concern raised in the original
post. I'm concerned with tools in general, not just compilers. Many
tools, such as IDEs and static analyzers, are unconcerned with compiled
forms of libraries; they only need access to source code. Historically,
tool providers have (almost) always been able to count on 1) headers
being available and discoverable via include paths, and 2) that they can
be parsed using the same include paths and macro definitions used to
parse source files that include them. Modules introduces the concern
that 1) the source for module interface units may not be available, 2)
there is no implicit mapping from module name to module interface unit
source file, and 3) that include paths and macro definition requirements
may differ across module interface units and their consumers.

>
> 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.

Tom.