[helloiamsomeone]

> find_package often just ends up using pkg-config

find_package() is just a souped-up include(). What happens once it finds the script matching the criteria provided by arguments and cache variables depends entirely on the script(s) (plural, because version criterion is satisfied by the *ConfigVersion.cmake script for config mode search) it runs. The PkgConfig module is only mentioned in a couple of CMake provided find modules:

    >find -maxdepth 1 -type f -name "Find*.cmake" -not -name FindPkgConfig.cmake -exec ugrep -HFe PkgConfig {} + | cut -d: -f1 | sort | uniq | sed s/..//;s/\.cmake//
    FindBLAS
    FindCURL
    FindCurses
    FindEXPAT
    FindFontconfig
    FindGLUT
    FindGSL
    FindGnuTLS
    FindImageMagick
    FindLAPACK
    FindLibXml2
    FindLibXslt
    FindLibinput
    FindMPI
    FindOpenSP
    FindOpenSSL

The prevalent method of discovering packages is via the package provided config scripts, which of course have to come from upstream. Kitware stopped adding new find modules, because they are not worth the maintenance effort (e.g. find modules require maintaining a list of versions like for Python or Boost) and instead upstreams should provide a proper CMake package.

pkg-config also really only works in the Linux bubble. CPS[1] is trying to bridge the gap here if you are interested.

[1]: https://github.com/cps-org/cps

[mdaniel]

I dunno why you linked to the specification repo, since reading over it and its included sample made it seem like the "current editor in chief"'s fever dream of JSON all the things

Only by going up to the repo listing does one find the actual implementation that alleges to replace pkg-config however <https://github.com/cps-org/cps-config#status> seems like "well, good luck" for the problem they're trying to solve. I mean, they couldn't even write down what does or doesn't work in order to know if I should bother learning its snowflake json schema? Not even a $(cps-config --import) to port over the bazillions of .pc files out in the wild