Date: Wed, 14 Mar 2018 19:06:55 +0100
FWIW,
Boris Kolpackov wrote:
> Corentin<corentin.jabot_at_[hidden]> 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_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
Boris Kolpackov wrote:
> Corentin<corentin.jabot_at_[hidden]> 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_[hidden]
> 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_[hidden]
Received on 2018-03-14 19:07:03