[CMake] pkg-config file format versus CMake packages

[Brad King]

On 05/25/2018 07:52 PM, Paul Fultz II wrote:
> What else is missing? 

The `.pc` format focuses on flat command-line strings that drop much
of the information used to generate them.  For example, if library
A depends on library B then the `.pc` file will record the link flags

   -L/path/to/A/lib -L/path/to/B/lib -lA -lB

There is no deep knowledge that the flags for "A" come from the current
package and the flags for "B" come from another package.  This
is okay as the *output* of a pkg-config query but such results could
be produced from an *input* format with a richer model.

The richer model is important when using more than one package at a
time.  If two packages have dependencies on B like the above example then
the -lB flags get duplicated.  Generating the proper combined order requires
deeper knowledge of the dependencies.  CMake's package configuration files
have this.

Some CMake "find modules" try to extract information from `.pc` files
by running pkg-config to get command lines.  They inevitably have to
parse the command lines and manually reconstruct things that could have
been put in the packaging files in a structured way in the first place.

> extending pkg-config seems like it would help adoption rather then
> creating a completely new format.

It would be nice if that would work.  However, most `.pc` files already
leave out much of the deeper information CMake likes to have.  Even
if we found a good way to represent that information in `.pc` files
projects would still need big updates to produce that information.

So long as the .pc or .cps format is supported by the pkg-config tool
I think adoption will be okay.

-Brad