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

Loïc Joly loic.actarus.joly at numericable.fr
Mon Sep 10 08:40:58 CEST 2018


Le 08/09/2018 à 04:16, Tom Honermann a écrit :
>
>>
>> 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. 

What do you propose to do?

I think closed-source library providers are happy to expose the 
interface of their code, but currently, in C++, headers contain many 
things related to implementation (private class members, template 
function bodies), and techniques to hide them have an impact on 
performance. So they provide the headers (or in some cases accept 
decreased performances/reduced features), but they would be very happy 
for a solution that allows them to avoid doing so. And I think 
delivering only compiled modules will have many attraction to them.

I think the way for tools to help users of those libraries is not to 
hope those library writers will be kind enough to continue providing 
headers. The tools will need something (inside or outside of the 
standard) that can at least partially understand the binary module 
artefacts. I think there are three ways to do that (two of which you 
already mentioned):

- Those artefacts have a standardized format. Tools can read that 
format. There has been strong reluctance from some compiler vendors 
against going that way. We will probably end-up with too many formats 
for tools to be able to read them, even if they are published/open 
sourced...
- Compilers provide a standardized API to read those. As you said, there 
does not seem to be many effort in this area, and we're not even sure 
the binary artefacts will contain all the data required by different tools.
- Compilers provide an option to generate a pseudo header out of a 
binary module artefact. This pseudo header does not need to be 
equivalent to the headers that were used to generate the module. For 
instance, it can be aggregated in one file, it can omit private class 
members, it can omit inline function definitions, non exported entities 
might in some cases be omitted... It's only used for tools to be able to 
know the interface of a module. A good aspect of this option is that it 
does not really require compiler vendors to agree on anything, so we 
might see it happening. A bad aspect is that we are not sure if it can 
be done with enough information for tools (can we extract comments, for 
instance, out of those binary artefacts?)

---
Loïc Joly





More information about the Tooling mailing list