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.

daniel