Re: [CMake] pkg-config file format versus CMake packages

[Brad King]

On 05/31/2018 01:41 PM, paul wrote:
> This is because cmake lacks native support for pkg-config. It only uses the
> pkg-config CLI, which works fine for makefiles.
> 
> Instead cmake needs to make a target for each `.pc` found. This could be
> possible if it used libpkgconf instead.

That sounds like a great feature that should be worked out first
to see how far it gets us.  Please bring it up on the developer list.

Thanks,
-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] pkg-config file format versus CMake packages

[paul via CMake]

On Thu, 2018-05-31 at 10:12 -0400, Brad King wrote:
> 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

No, it would record it as:

Requires: B

It would only record it as `-L/path/to/A/lib -L/path/to/B/lib -lA -lB` if B
didnt support pkg-config. This same problem exists for cmake if the user
doesn't use a separate target for library B.

> 
> 
> 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.

This is because cmake lacks native support for pkg-config. It only uses the
pkg-config CLI, which works fine for makefiles.

Instead cmake needs to make a target for each `.pc` found. This could be
possible if it used libpkgconf instead.

Even more so, we could support a `cmake_target` variable so .pc files could
specify the cmake target name.

> 
> > 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.

Projects would need to be updated for cps as well, but it seems a few tweaks
to pkg-config is more likely to be accepted than adding a new file format.

Paul
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [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
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] pkg-config file format versus CMake packages

[Paul Fultz II via CMake]

> On May 26, 2018, at 5:08 AM, Lectem  > 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

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] pkg-config file format versus CMake packages

[Hendrik Sattler]

Hi,

I often found pkg-config files to be even wrong. Many library authors do not 
seem to know the rules for transitive linking. Often, the differences between 
static and dynamic linking is not or wrongly expressed in .pc files. Cross 
compiling with pkg-config is also not being the most fun unless the library 
author thought about it or you fix the files yourself.

You don't have to care so much about ABI, different compilers and such. On most 
systems, these need different directories and thus separate .pc files.

CMake also fails late at linking even pointing it to Qt 64bit libraries for a 
32bit compiler even though they use config modules! At some point, it's the 
responsibility of the developer to organize his environment correctly.

Regards,

HS



Am 26. Mai 2018 12:08:01 MESZ schrieb Lectem :
>
>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), and does not provide any
>information about things such as ABI, C-runtime Library used (arguably
>could be represented as a package ?). 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.
>
>
>Have a nice Week-end,
>Lectem
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] pkg-config file format versus CMake packages

[Lectem]

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


Have a nice Week-end,
Lectem
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] pkg-config file format versus CMake packages

[Paul Fultz II via CMake]

> On May 25, 2018, at 8:07 AM, Brad King  wrote:
> 
> On 05/24/2018 07:39 PM, Paul Fultz II wrote:
>>> On May 24, 2018, at 8:07 AM, Brad King wrote:
>>> The `.pc` file format is too flat to lend itself well to representing
>>> all the information we need.  
>> 
>> What do you mean? What information can't be represented?
> 
> Try running CMake's ExportImport test and take a look at the
> files generated by export() and install(EXPORT).  If anyone
> can use `.pc` files as a package representation for everything
> that test does on all platforms then I'd like to see a proposal.

Yes, and what seems to be missing from pkg-config to represent that information 
is the ability to put a direct path to the library(instead of using the -l and 
-L flags), and support for a `Replaces` field. 

This is also the same shortcomings talked about in the CPS document as well. 
Resolving these shortcomings, will allow pkg-config to represent the same thing 
as CPS and cmake. What else is missing? 

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.

Paul
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] pkg-config file format versus CMake packages

[Brad King]

On 05/24/2018 07:39 PM, Paul Fultz II wrote:
>> On May 24, 2018, at 8:07 AM, Brad King wrote:
>> The `.pc` file format is too flat to lend itself well to representing
>> all the information we need.  
> 
> What do you mean? What information can't be represented?

Try running CMake's ExportImport test and take a look at the
files generated by export() and install(EXPORT).  If anyone
can use `.pc` files as a package representation for everything
that test does on all platforms then I'd like to see a proposal.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake