So it seems like the challenge here will be to get buy-in from all these
different parties that they should support some common format?

I guess the request to the committee would be to bless one in some way
(some sort of non-standard, but standard-adjacent document? with some form
of the weight of the committee behind it) in the hopes that that will help
add more weight to the feature requests on these tools to add support for
this format?

On Fri, Jun 18, 2021 at 11:40 AM Poliakoff, David Zoeller <
dzpolia_at_[hidden]> wrote:

> 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]> wrote:
>
> On Fri, Jun 18, 2021 at 2:12 PM David Blaikie <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)?
>