[CMake] pkg-config file format versus CMake packages

[Paul Fultz II]

> On May 26, 2018, at 5:08 AM, Lectem <lectem at gmail.com <mailto:lectem at gmail.com>> wrote:
> 
>  
> Hi,
> I’ll start by saying that I love the fact we’re now talking about a common representation of packages !
>  
> The reason I say this is that extending pkg-config seems like it would help adoption rather then creating a completely new format. There is already a good portion of open source projects that already support pkg-config, so tweaking them to support more complicated scenarios seems easier than converting everything to a new format.
>  
> I’m not very familiar with pkg-config (working more in the Windows world) so excuse me if I’m wrong.
>  
> From what I remember it is very basic and relies on compiler flags being the same everywhere (ie gcc-like flags),

The flags are only written gcc-like for include paths, defines, library paths. Pkg-config(and cmake) converts these flags to the native versions. Outside of these flags they are tied to the compiler, which is the same for cmake as well.

> and does not provide any information about things such as ABI, C-runtime Library used (arguably could be represented as a package ?).

Yes, this can be another package that can be added to the `Requires` field.

> As far as I know, it assumes that the libraries are always compiled with the same compiler on the same system, hence has no knowledge of compatibility between compiler versions. 
> As you mentionned, it currently relies on -l for both libraries and linker flags, which would need to be changed.
>  
> so tweaking them to support more complicated scenarios seems easier than converting everything to a new format.
>  
> Wouldn’t that create more confusion ? I fear it’d end up as a python2 python3 issue, where both versions look alike but are incompatible.

These changes are all backwards-compatible(that is the current pkg-config files will continue to work). Having standard packages to represent different ABI or requirements can be supported with the current pkg-config. And, pkg-config already supports a `Provides` field(ie `Replaces` field).

Allowing a file instead of -l flag is a minor change. Pkg-config file format has not been static and has changed and evolved over the years(like adding the private fields or dollar sign escaping).

Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180526/f774034a/attachment.html>