Date: Fri, 18 Jun 2021 18:40:51 +0000
Generally users beat us up until we support as many of those as we can stand. In the Kokkos case we’ve limited it to CMake support for discovering us as an installed package, but I’ve been on projects where you install CMake and pkg-config and the script that helps the guy down the hall’s homegrown build system…
Best,
David P
From: SG15 <sg15-bounces_at_[hidden]> on behalf of David Blaikie via SG15 <sg15_at_[hidden]>
Reply-To: "sg15_at_[hidden]" <sg15_at_[hidden]>
Date: Friday, June 18, 2021 at 12:38 PM
To: Daniel Ruoso <daniel_at_[hidden]>
Cc: David Blaikie <dblaikie_at_[hidden]>, "sg15_at_[hidden]" <sg15_at_[hidden]>
Subject: [EXTERNAL] Re: [SG15] Draft: Requirements for Usage of C++ Modules at Bloomberg
On Fri, Jun 18, 2021 at 11:28 AM Daniel Ruoso <daniel_at_[hidden]<mailto:daniel_at_[hidden]>> wrote:
On Fri, Jun 18, 2021 at 2:12 PM David Blaikie <dblaikie_at_[hidden]<mailto:dblaikie_at_[hidden]>> wrote:
But, going on past experience, those kinds of utilities/dependencies don't necessarily eventuate and I can understand the concern about proliferation/variation/lack of ubiquity in such things & so a preference to bake it into a common config file. I guess all I have on that is that I think it'd be unfortunate for developers to have to repeat this information in multiple places like that.
Right. In a sense, I'm putting forward a thesis that the heterogeneity that exists today on how to consume pre-built artifacts (pkg-config, CMake find modules, ad-hoc "pg_config"-style tools) becomes even more unsustainable after Modules, because of the separate parsing context for each module interface, and the required DAG-bound parsing of modules.
IOW, headers were trivial enough for the build system that we could survive the heterogeneity, but Modules have considerably more complex semantics, making the status-quo untenable for non-monorepo use cases.
I don't have loads of experience with the situation as it exists today - do distributions generally standardize this? (ie: make sure all their packages have pkg-config, or that they all have CMake find modules, etc)?
Best,
David P
From: SG15 <sg15-bounces_at_[hidden]> on behalf of David Blaikie via SG15 <sg15_at_[hidden]>
Reply-To: "sg15_at_[hidden]" <sg15_at_[hidden]>
Date: Friday, June 18, 2021 at 12:38 PM
To: Daniel Ruoso <daniel_at_[hidden]>
Cc: David Blaikie <dblaikie_at_[hidden]>, "sg15_at_[hidden]" <sg15_at_[hidden]>
Subject: [EXTERNAL] Re: [SG15] Draft: Requirements for Usage of C++ Modules at Bloomberg
On Fri, Jun 18, 2021 at 11:28 AM Daniel Ruoso <daniel_at_[hidden]<mailto:daniel_at_[hidden]>> wrote:
On Fri, Jun 18, 2021 at 2:12 PM David Blaikie <dblaikie_at_[hidden]<mailto:dblaikie_at_[hidden]>> wrote:
But, going on past experience, those kinds of utilities/dependencies don't necessarily eventuate and I can understand the concern about proliferation/variation/lack of ubiquity in such things & so a preference to bake it into a common config file. I guess all I have on that is that I think it'd be unfortunate for developers to have to repeat this information in multiple places like that.
Right. In a sense, I'm putting forward a thesis that the heterogeneity that exists today on how to consume pre-built artifacts (pkg-config, CMake find modules, ad-hoc "pg_config"-style tools) becomes even more unsustainable after Modules, because of the separate parsing context for each module interface, and the required DAG-bound parsing of modules.
IOW, headers were trivial enough for the build system that we could survive the heterogeneity, but Modules have considerably more complex semantics, making the status-quo untenable for non-monorepo use cases.
I don't have loads of experience with the situation as it exists today - do distributions generally standardize this? (ie: make sure all their packages have pkg-config, or that they all have CMake find modules, etc)?
Received on 2021-06-18 13:40:55