[catern]

>Antipatterns: Often your Makefiles have to be hardcoded to assume pkg-config.

I'm not clear what you mean here - are you suggesting "hard-coding" use of pkg-config is a bad thing? Why? "Hard-coding" pkg-config would be ideal, I think, since pkg-config is the only package-manager-independent option that I know of for native dependencies...

[humanrebar]

On paper pkg-config is in the right general direction. Shipping package metadata alongside binaries is probably required to solve the problems I sketched out. And topologically sorting that data makes a ton of sense.

A few problems though:

A. Its model could be more robust. There is no way to specify a language runtime dependency other than providing non-portable linker and compilation flags. Cycles in search paths are easy to introduce, partly because there search paths aren't modeled as such. Instead, flags are just graphed and flattened.

B. To generalize on A, pkg-config very much travels in terms of non-portable flags that you flatten. It would be more useful, arguably essential, to be able to simply export a graph of metadata.

C. In theory pkg-config is portable. In practice, uptake on Windows is underwhelming to be generous. And many Linux distros treat that sort of metadata as optional for native packages as well.

But within a given distro, I have seen pkg-config work well enough. It might be the closest we have to a standard in this space. If the major build systems like CMake and bazel supported exporting cross-compatible .pc files, and then if distros required .pc files (with consistent names!) every time a header was shipped, we would be taking a big step in the right direction.

[jcelerier]

Only on unix-like systems, and even there...