Document how to preserve PkgConfig data from package method

[uilianries]

Hello!

Originally we have few issues in ConanCenterIndex affected by the scenario where pkg-config is not installed in the system, so users can not consume those packages that are simple wrappers for system libraries:

• https://github.com/conan-io/conan-center-index/issues/23009
• https://github.com/conan-io/conan-center-index/issues/14909

Indeed I was caught by this error when using a raw docker image to validate a reported bug in Ubuntu 24.04. This is my motivation for writing this PR.

As possible alternative (experimental), we can run PkgConfig from package() and store its data in a json file, then, restore that information in self.cpp_info. This workaround was commented by Memsharded 1 year ago: https://github.com/conan-io/conan/issues/14422#issuecomment-1665166761

This scenario is tested already in Conan client, but not well explored, still, is working in minimal case: https://github.com/conan-io/conan/blob/c55ab23d01f1336c850816e07c68ae19704201d6/test/functional/toolchains/gnu/test_pkg_config.py#L99

Related to https://github.com/conan-io/conan/issues/14422.

Current preview (commit c313918):

---

EDIT:

After those comments pointed at https://github.com/conan-io/docs/pull/3811#pullrequestreview-2235749056, I removed the part of "This is a useful feature when packaging a system library" and added an warning box about not using this new approach for system package due possible incompatibility.

[uilianries]

@jcar87 @memsharded I just addressed your comments into the commit https://github.com/conan-io/docs/pull/3811/commits/e23b7c217dd462e992e392d53ce1b2aa2b8c5a18

• No more system package recommendation in the feature description
• Added Warning box to clarify that using system package with cached information is risky.

Please, review it again.

[rohel01]

Hello, this documentation update does not show up on the documentation site. I looked at the documentation for releases 2.6, 2.7, 2.15 and 2.16. Am I missing something?

[memsharded]

Hi @rohel01

Thanks for noticing this! It seems this PR was never merged, not sure what happened, let us check

[rohel01]

Hello, any update on this? The added documentation is very useful

[jcar87]

Hello, any update on this? The added documentation is very useful

Hi @rohel01, thanks for reaching out.

This has not been merged as we have gained a better understanding of pkg-config and have identified some issues in Conan Center.

Our current recommendations are as follows:

• All of the recipes in Conan Center that are wrappers for the system package manager on Linux and FreeBSD - the users must have the system's pkg-config (or equivalent) installed - this has always been the case, but is now reflected in the Conan Center documentation: https://github.com/conan-io/conan-center-index/blob/05bebf9e25d4af0abe883ad15c517a0803f0dd0c/docs/consuming_recipes.md#expected-environment . Would very strongly recommend to set the tools.gnu:pkg_config config in the profile, pointing to the system-provided pkg-config executable. There are mainly two reasons for this:
  • The pkg-config provided by the system package manager designed to work with the .pc files provided by the same system package manager. That is, it KNOWS to not emit -I/usr/include, -L/usr/lib/, -L/usr/lib/x86_64-linux-gnu or similar as flags. This is very important. The pkgconf package from Conan Center does not know to properly remove these, and they vary from distro to distro or within the same distro for different architectures. I have seen approaches proposed where the system pkg-config is queried to determine which paths we need to tell the pkgconf from the recipe to remove... which would involve using both, and I'm not sure the fragility is warranted.
  • A package_info() method that invokes pkg-config (in Conan Center this only happens for recipes where the version is simply "system" - is not able to call pkg-config provided by a recipe - because package_info() is often invoked in a context where the graph is not resolved.

The approach proposed in this PR would be suitable for:

• a library that is built from source
• that produces a .pc file
• where we want to "lift" the data from the .pc file to fill the contents of cpp_info in the package_info() method
• there are no dependencies on "system" libraries that need to be resolved

let us know if these are the patterns that are relevant to you, or if we are missing something, thanks!