On 18/06/2021 19.19, David Blaikie via SG15 wrote:
> I agree that the N+1 problem is a real concern - hence bringing up whether
> pkg-config might be the wagon we could hitch our cart to in this regard (or
> some other existing solution that could be fleshed out and more strongly
> encouraged (than in the past) as "the" tool to use here, with some
> expectation/desire/buy-in from other tool vendors (like cmake) that they'd
> be on board with that direction).
>
> Be good to get some of the relevant tooling folks (the cmakes, etc, of the
> world) to see what they think would be a good path forward for them.

Here's a good exercise: someone advocating pkg-config should write a
tool that converts a conforming CPS¹ to pkg-config *without loss of
information*. If that can be accomplished, it would go a long way toward
demonstrating that pkg-config is a suitable format. I've heard a lot of
people making that claim, but I'm not aware of anyone seriously trying
to back it up. (Admittedly, I don't have the time to dig into it too
much, and am not as involved with build systems now as I was a few years
ago. What I want to see, however, is a concerted effort being made to
replace CMake's native package scripts.)

Another point in favor of CPS: it's JSON. The format recommended by
P1689 is also JSON. This means that, at least at a lexical level, only
one parser — and one which is widely available across many languages —
is needed for both formats. This would not be the case with pkg-config.

(¹ https://mwoehlke.github.io/cps/)

-- 
Matthew