Contribute Find-module to CMake vs Config-file to upstream

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: 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
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>:

 

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
Reply | Threaded
Open this post in threaded view
|

Re: pkg-config file format versus CMake packages

CMake mailing list
In reply to this post by Lectem

On May 26, 2018, at 5:08 AM, Lectem <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: pkg-config file format versus CMake packages

Brad King
In reply to this post by CMake mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: pkg-config file format versus CMake packages

CMake mailing list
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
Reply | Threaded
Open this post in threaded view
|

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