Meson: fix pkgconf sysroot prefix to conan paths when cross-compiling

[wdobbe]

Currently when a package uses the Meson build helper classes sometimes the include and library paths to other Conan packages in the cache are prefixed with the toolchain sysroot path. This will cause the build to fail because the Conan packages are located outside the toolchain sysroot. See issue #16468.
This happens when the include and/or lib path are retrieved with pkgconf. If a sysroot path is passed to pkgconf it will prefix all -I and -L paths with the sysroot path. To prevent this you can set environment variable PKG_CONFIG_FDO_SYSROOT_RULES, which is what this PR does.
Examples of CCI packages that currently fail when cross-compiling are:

• freetype
• fontconfig
• harfbuzz
• glib

Fixes #16468.

Changelog: (Fix): Meson: do not prefix toolchain sysroot path to include and lib paths to Conan packages when cross-compiling.

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

[CLAassistant]

All committers have signed the CLA.

[wdobbe]

The current commit in this PR doesn't work, the environment variable PKG_CONFIG_FDO_SYSROOT_RULES is not set when the Meson configure step runs. I am reading the Conan documentation how to add a variable to the build environment but haven't found the solution yet. Help is appreciated.

[memsharded]

Thanks for your contribution @wdobbe

It is generally better to start with a test that fails without the fix, then apply the fix to get a green test. That helps a lot understanding the original issue.

[memsharded]

Setting an environment variable this way is not correct, it will leave the environment dirty for other packages, etc. If anything, the approach would be in the MesonToolchain generator, to generate a Environment script with the necessary env-vars

[jcar87]

As of Conan 2.23, which was released yesterday (#19229)

Conan no longer passes the sysroot to meson as a variable - it caused pkg-config to unconditionally prefix the paths in a way that did not work.

Please note that the environment variable referenced in this PR only applies to the pkgconf implementation , which is not always guaranteed to be used (Conan doesn't know which implementation is being used, or if a version that supports that variable is being used). Also looking at the changelog, it looks like it may need DESTDIR (or interact with DESTDIR in some ways) and may have different behaviour with linker/include paths vs variables.

pkg-config (and pkgconf), when invoked without further information, fall back to the locations they expect that they have hardcoded when they were compiled. Not every distro follows the same convention (e.g /usr/lib vs /usr/lib/aarch64-linux-gnu).

It is very important to get this right, because otherwise incorrect use may cause the different tools to pass -I/path/to/sysroot/usr/include (or similar), and if the sysroot contains the same dependencies that come from Conan, they would then have a higher priority than they should, leading to potential conflicts (compiler, linker or runtime errors).

So when working with a sysroot, it's really important to "override" the internals and ensure that pkg-config reflects the layout of the sysroot, while still giving higher priority to Conan dependencies -
please see #19311 (comment) for details

There are a number of issues reported for pkgconf:

• Don't prepend sysroot_dir if pkg-config file lies outside of sysroot_dir pkgconf/pkgconf#226
• PKG_CONFIG_SYSROOT_DIR get also prepended to libraries outside of SYSROOT pkgconf/pkgconf#213
• PKG_CONFIG_SYSROOT_DIR incompatible between pkg-config and pkgconf pkgconf/pkgconf#251
• The sysroot is duplicated when using ${pc_sysrootdir}/${prefix} or similar pkgconf/pkgconf#123

All with subtle differences, depending on the specific version, and bearing in mind that they may not apply to the older pkg-config at all, which some may still be using.

My recommendation would be a wrapper script like the following:
#19311 (comment)
that's the most robust solution we've been able to find,