Date: Tue, 12 Feb 2019 17:37:45 -0500
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.
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.
>
>
>
>
>
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.
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.
>
>
>
>
>
Received on 2019-02-12 23:37:59