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

Tom Honermann tom at honermann.net
Sat Sep 8 04:16:15 CEST 2018


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.


More information about the Tooling mailing list