Date: Tue, 12 Feb 2019 20:34:10 +0000
* I suspect Distributions Maintainers could get great performance improvements if they can find a way to share BMI accross all build of packages for a given compiler version.
Right. My expectation is to install the BMIs along the interface source files.
From: tooling-bounces_at_[hidden] <tooling-bounces_at_[hidden]> On Behalf Of Corentin
Sent: Tuesday, February 12, 2019 12:29 PM
To: ben.boeckel_at_[hidden]; WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
Cc: michael_spencer_at_[hidden]
Subject: Re: [Tooling] Modules feedback
On Tue, 12 Feb 2019 at 20:50 Ben Boeckel <ben.boeckel_at_[hidden]<mailto:ben.boeckel_at_[hidden]>> wrote:
On Tue, Feb 12, 2019 at 19:32:45 +0000, Gabriel Dos Reis wrote:
> IPR isn’t for distribution.
OK. Substitute whatever format we end up using for distribution of
modules within RPM, DPKG, vcpkg, ports, etc. It just can't be "nothing"
because otherwise modules are effectively only useful in monorepo
build-the-world-from-scratch projects. Which is not how C++ works today
in the realm of FOSS. And it is best if that format is compatible
between otherwise-compatible compilers too.
Linux distributions are rather interesting
Internally, they are very much built from source in that all packages are built in
in a similar environment - to some extent.
Except packages aren't necessarily rebuilt when the compiler changes.
(Debian rebuilt everything last time C++ broke abi)
Externally, it is standard practice to consume the libraries of the distribution from projects that may not use the same compiler.
So Shipping BMI would be counterproductive on Linux.
Instead, you would ship the headers and the Module Interface Units source files*,
And you would consume them by generating a BMI then go on with your build and
get some compile-time benefits if the BMI is used in multiple TU.
I suspect Distributions Maintainers could get great performance improvements if they can find a way to share BMI accross all build of packages for a given compiler version.
Similarly vcpkg and ports are, very sanely, source-based.
They wouldn't function differently than today.
* Reason 47 to have a deterministic mapping from module name to Module Interface Units identifier.
--Ben
_______________________________________________
Tooling mailing list
Tooling_at_[hidden]<mailto:Tooling_at_[hidden]>
http://www.open-std.org/mailman/listinfo/tooling<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7C07d8d616f08241da52e208d69128bcde%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636856001499548517&sdata=bJTgmvIDLY8gysyNgGPjE4pkvWloMIm9%2BZOmSbpTTgk%3D&reserved=0>
Right. My expectation is to install the BMIs along the interface source files.
From: tooling-bounces_at_[hidden] <tooling-bounces_at_[hidden]> On Behalf Of Corentin
Sent: Tuesday, February 12, 2019 12:29 PM
To: ben.boeckel_at_[hidden]; WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
Cc: michael_spencer_at_[hidden]
Subject: Re: [Tooling] Modules feedback
On Tue, 12 Feb 2019 at 20:50 Ben Boeckel <ben.boeckel_at_[hidden]<mailto:ben.boeckel_at_[hidden]>> wrote:
On Tue, Feb 12, 2019 at 19:32:45 +0000, Gabriel Dos Reis wrote:
> IPR isn’t for distribution.
OK. Substitute whatever format we end up using for distribution of
modules within RPM, DPKG, vcpkg, ports, etc. It just can't be "nothing"
because otherwise modules are effectively only useful in monorepo
build-the-world-from-scratch projects. Which is not how C++ works today
in the realm of FOSS. And it is best if that format is compatible
between otherwise-compatible compilers too.
Linux distributions are rather interesting
Internally, they are very much built from source in that all packages are built in
in a similar environment - to some extent.
Except packages aren't necessarily rebuilt when the compiler changes.
(Debian rebuilt everything last time C++ broke abi)
Externally, it is standard practice to consume the libraries of the distribution from projects that may not use the same compiler.
So Shipping BMI would be counterproductive on Linux.
Instead, you would ship the headers and the Module Interface Units source files*,
And you would consume them by generating a BMI then go on with your build and
get some compile-time benefits if the BMI is used in multiple TU.
I suspect Distributions Maintainers could get great performance improvements if they can find a way to share BMI accross all build of packages for a given compiler version.
Similarly vcpkg and ports are, very sanely, source-based.
They wouldn't function differently than today.
* Reason 47 to have a deterministic mapping from module name to Module Interface Units identifier.
--Ben
_______________________________________________
Tooling mailing list
Tooling_at_[hidden]<mailto:Tooling_at_[hidden]>
http://www.open-std.org/mailman/listinfo/tooling<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7C07d8d616f08241da52e208d69128bcde%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636856001499548517&sdata=bJTgmvIDLY8gysyNgGPjE4pkvWloMIm9%2BZOmSbpTTgk%3D&reserved=0>
Received on 2019-02-12 21:34:13