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)?