On Tue, 12 Feb 2019 at 23:38 Steve Downey <sdowney_at_[hidden]> wrote:

> Separately from general packaging, I do want to see a solution to getting
> bmi from a nightly build, just so I don't have to teach my build to build
> every transitive BMI, I can just use them. This would be in a tightly
> controlled environment, same compiler, mostly same flags, etc. Even if the
> time is de minimus for one, there are a lot of them. Assuming that we have
> one module per component, which is our desired state.
>

If you have a controlled environment there should be no issue.

I think the following could help with caching bmi safely


 * A mechanism by which given a set of compilation flags, a compiler would
generate a string that would be identic for all set of compilations that
might not
result in a different output

g++ -id foo.cpp
abc
g++ -id foo.cpp -Wall
abc
g++ -id foo.cpp -O3
dfe

This would let you cache the BMI

 * A mechanism to generate a string from a Module Interface Unit or a BMI
such that the same string would be generated for 2 BMI if they have the
same ABI



>
> On Tue, Feb 12, 2019 at 5:33 PM Steve Downey <sdowney_at_[hidden]> wrote:
>
>>
>>> Right now, they ship headers. They can't ship BMI's because BMI's are
>>> not portable across compilers or quite possibly even compiler versions.
>>> Shipping raw source will not be an option for non-open-source libraries.
>>>
>>> We need an intermediate representation that is *portable*.
>>>
>>> Source for the module interface. If you don't want to provide details in
>> the module interface, then don't. You are no worse off than if you provided
>> headers.
>>
>> export module my_closed_source;
>> export import "my_closed_source_header.h"
>>
>> We do need some ground rules for how to consume the source of an
>> interface unit. I believe the compiled interface should be in a library, or
>> otherwise provided, and the consumer just translate the interface into the
>> bmi, because providing a .o and a .a to a posix linker has very different
>> effects. The object file is added unconditionally, and its undefs must be
>> resolved, where a library is just a source for undef resolution.
>>
>>
>>
>>
>>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>