specifying dependencies on projects without cps

[dcbaker]

One of the pain points of pkg-config is that specifying that a pkg-config dependency that has a non-pkg-config dependency is really awful. You basically just say "here's some -I -l and -L options, hopefully everything works out." It would be nice if CPS had a way to specify that it depended on non-cps dependencies. I see a couple right off the bat

• pkg-conifg
• cmake-config

Neither of these are going to go away just because CPS is suddenly released, at least not immediately.

• Apple frameworks
  These are never going to go away, and we have no power over them. being able to add them as a dependency would be very useful.

[bretbrownjr]

Current plans are to implement full CPS support in CMake, so hopefully the CMake config files will be moot over time. Supporting those seems like a very nontrivial project for anything not implemented in CMake.

I share the desire to provide some sort of support for pkg-config. I expect it will be a practical requirement for this project... to provide a seamless onramp to CPS. I'm not sure CPS needs to define support for pkg-config or if that's an exercise for tools that consume CPS.

I do have an idea for a cps-query command-line tool (see #33). Eventually, being able to respect pkg-config to a reasonable degree seems like an achievable goal.

[dcbaker]

Meson has support for them, by running CMake with some custom cmake files that find a dependency and then use message() to communicate, haha. But I guess that's not something most other build systems have done (and yes, it's as fragile as it sounds).

I'm a Linux person, who often has to interact with LTS releases (RHEL, Ubuntu LTS, CLES, Debian oldstable). I have real concerns that it could be years before we can rely on 1) projects shipping CPS 2) distros having new enough tools to use CPS.