[Tooling] Portable Module Representation

Peter Sommerlad peter.sommerlad at hsr.ch
Wed Mar 14 19:06:55 CET 2018


FWIW,

Boris Kolpackov wrote:
> Corentin<corentin.jabot at gmail.com>  writes:
>
>> I propose that conforming compilers must generate when compiling a module
>> interface both:
>>   * A non portable, implementation-defined module interface file that may be
>> digested by that specific compiler (like it is the case today, as per the
>> module TS)
>>   * A defined, non compiler specific "universal" module interface
>> representation.
>
> Another alternative would be to define an API (naturally in C++ -- it's
> about time we stopped using other languages for implementing our tools)
> that can be used to query the compiler-specific binary module interface
> (BMI) files. Each compiler vendor will then provide an implementation
> of this API for their format.

Dependencies are important for more than compilers. There are at least 
two IDE implementations that are not using C++ as their implementation 
language and that are not compilers (they call out to multitude), but 
need to do parsing and analysis and might need to figure out where 
modules etc reside and what is their content (source or not) to provide 
useful tooling.

>
>
>> Libraries could then be distributed with those modules representations
>> [...]
>
> Distributing anything generated opens a can of worms. For example, does
> it mean we check-in these representations into VCS since these days this
> is the way things are often "distributed"?
>
>
>> For package managers, it could provide a mean to enforce semver at the API
>> level (aka that, the dependent project will still build when the source
>> dependency is updated, as long as they don't depend anything else than the
>> formally describe API).
>
> Yes, having a formal API compatibility verification would be very nice
> indeed.

Can we define a text-only format for representing some of this stuff 
(JSON-based?), that would help a lot.

Peter.


>
> Boris
> _______________________________________________
> Tooling mailing list
> Tooling at isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/tooling

-- 
Prof. Peter Sommerlad

Institute for Software: Better Software - Simple, Faster!
HSR Hochschule für Technik Rapperswil
Oberseestr 10, Postfach 1475, CH-8640 Rapperswil

http://ifs.hsr.ch http://cevelop.com http://linticator.com
tel:+41 55 222 49 84 == mobile:+41 79 432 23 32
fax:+41 55 222 46 29 == mailto:peter.sommerlad at hsr.ch



More information about the Tooling mailing list