[bug] PkgConfigDeps: Separate pkg-config files between the host and build contexts by directory

[jwillikers]

What is your suggestion?

Currently, the PkgConfigDeps generator allows placing only specific dependencies in the build context by opting to explicitly indicate them as such and even requires renaming them when used in both the build and host contexts.
This functionality is primarily used by Meson projects which use pkg-config files to find build tools, such as how xkbcommon and wayland find the wayland-scanner program provided by the wayland package.
The current approach is problematic for multiple reasons.

1. It requires explicitly defining which tool_requires packages should be available in the build context for PkgConfigDeps, which requires more work effort in the conanfile.py.
2. Renaming pkg-config files always requires a corresponding patch to the consumer's build system to find the renamed pkg-config file.
3. It's potentially necessary to manually work out the dependencies of all packages placed in the build context and to add each of the dependencies to build_context_activated to ensure that all dependencies are found properly by pkg-config. Currently, everything falls apart here when renaming an individual package with a build context suffix, as the dependencies listed as Requires of the renamed pkg-config files are not themselves renamed, resulting in pkg-config files in the build context requiring pkg-config files in the host context.
   Here's an example of wayland-scanner_BUILD.pc demonstrating this predicament.

   prefix=/home/jordan/.conan/data/wayland/1.22.0/_/_/package/3bac7fb7b73d7ba4f2368553fe0e26308f7b9f0b
   # Custom PC content
   datarootdir=${prefix}/res
   pkgdatadir=${datarootdir}/wayland
   bindir=${prefix}/bin
   wayland_scanner=${bindir}/wayland-scanner
   
   Name: wayland-scanner_BUILD
   Description: Conan component: wayland_BUILD-wayland-scanner_BUILD
   Version: 1.22.0
   Libs: 
   Cflags: 
   Requires: expat libxml-2.0
   

   Note that it requires expat while expat.pc is in the host context and not the build context.
   No expat_BUILD.pc is generated automatically, either.
4. In Meson, it's necessary to explicitly define tc.project_options["build.pkg_config_path"] = self.generators_folder to add the generators directory to the pkg-config search path for native packages.

An alternative approach is to separate the pkg-config files for the host and build contexts by directory rather than by renaming pkg-config files.
This solves the three problems with the current approach.

1. The pkg-config files can be safely generated for all build and host requirements automatically.
2. The generated pkg-config files can safely use the same names, as they are placed in separate directories. No patching is necessary.
3. The pkg-config files for all dependencies can be produced automatically.
4. The Meson generator can automatically define the build.pkg_config_path to point to the directory containing the pkg-config files in the build context.

There are a couple of drawbacks to this approach.

1. It can result in the generation of extraneous pkg-config files which are not required when building a package, especially when building non-Meson projects which don't appear - in my limited experience - to find dependencies in the build context in this manner.
2. Changes to PkgConfigDeps must not break existing packages, requiring careful consideration of how this is implemented.
3. The MesonToolchain generator needs to be aware when pkg-config directories are being used for both the build and host contexts so that it can define pkg_config_path and build.pkg_config_path appropriately.

To address the concerns, perhaps the implementation could follow a similar approach to VirtualBuildEnv and VirtualRunEnv where separate generators are used per context or the existing PkgConfigDeps could be modified to provide a different constructor or to provide an option to generate pkg-config files for build dependencies in a separate directory from host dependencies.
The implementation could still require consumers to declare specific dependencies to provide in the build context, if desired, to reduce the number of pkg-config files generated, but dependencies of any such package should automatically have pkg-config files generated in the build context as well to ensure that transitive dependencies can be found if needed.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[ericLemanissier]

this is related to #12342

[jwillikers]

this is related to #12342

That's where that went! 🤯 I knew I'd brought this up before somewhere. Thanks @ericLemanissier!

[franramirez688]

Hi @jwillikers

Thanks for reporting it and the great explanation!
Also, I saw the related issue was opened a long time ago 😢 Sorry about the delay in looking into this issue.

I was thinking of this one yesterday, and it seems like a bug instead of a feature, doesn't it?
Indeed, PkgConfigDeps is not isolating the whole build context, and the build context suffixes management is not helping so much. I need to perform a test to see it better, but yes, IMO, looks like a bug.
I'll update this issue when I have a PR or any other further investigations.

[memsharded]

Implemented in #15813 for next Conan 2.2