[feature] add prefix var to pkg-config alias

[bruchar1]

What is your suggestion?

When a package contains components, conan pkg-config generator generates one .pc file per component, plus a root .pc file that includes all the components .pc files.

However, the generated root .pc file does not contain the prefix variable. When I use the meson build system, I may need to access that variable, since this is the easiest way to get the location of the installed conan package. For instance, I may need this path to find a tool installed along with this pacakge. An other example is the boost package. meson expects the boost.pc package to have the prefix variable, and not having it causes issues (mesonbuild/meson#11487 was an attempt to fix this on the meson side, but the real problem is on the conan generated file, imho).

Another problem with the generated root .pc file is that it doesn't honnor the pkg_config_custom_content property. Therefore, it is not possible to inject custom contents in the generated root .pc file.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @bruchar1

The PR #17568 has been merged, as a refactor.
This PR removes the {prefix} exclusively from alias pc files, but not from the root. We have seen that there are only 3 usages of pkg_config_aliases in ConanCenter, so it seems this is a very rarely used feature, as today we would have probably not added it, as Conan allows to override pkg_config_name property on consumers for special cases.

As I understand the above, the main usage for this request and #14051 was to have it in the "root" pc file. This has not been removed, and it is still there.

Can you please confirm if your use case was about the "root" pc files, or about the aliased (defined with ````pkg_config_aliases``) ones?

[bruchar1]

Yes, I think this is correct. The {prefix} was mainly required for the integration of the boost package with meson, and it doesn't use pkg_config_aliases.

[memsharded]

Great, thanks very much for the feedback!
Then we are leaving the refactor #17568 for next 2.12