pkg-config path used in dependency(..., native:true) is sometimes incorrect

[ghost]

I have found that when doing cross compilation if you first call host dependency() and then dependency(native: true), then dependency(native: true) will use pkg-config path that is used (and cached) by dependency().

When I change the order, everything is ok. There's some caching of pkg-config paths going on, and in this specific case, it goes wrong.

[nirbheek]

This is another bug in the caching of dependencies. It's easy to fix it. Will provide a patch.

[ghost]

This needs to be re-open, because it is still broken.

[ghost]

This patch fixes the issue (stop cachig cross pkg-config into the same var that later can get used to fetch the native pkg-config incorrectly):

diff --git a/mesonbuild/dependencies/base.py b/mesonbuild/dependencies/base.py
index 864fd736..b14d8c6b 100644
--- a/mesonbuild/dependencies/base.py
+++ b/mesonbuild/dependencies/base.py
@@ -448,7 +448,6 @@ class PkgConfigDependency(ExternalDependency):
                 potential_pkgbin = ExternalProgram.from_cross_info(environment.cross_info, 'pkgconfig')
                 if potential_pkgbin.found():
                     self.pkgbin = potential_pkgbin
-                    PkgConfigDependency.class_pkgbin = self.pkgbin
                 else:
                     mlog.debug('Cross pkg-config %s not found.' % potential_pkgbin.name)
         # Only search for the native pkg-config the first time and

[ghost]

Can we please get this fixed? Here's a test case and a fix, please pull:

https://megous.com/git/meson/log/?h=issue-1736

Test cases depend on the presence of the cross-compiled zlib and someone not using --prefix=/usr for cross build. It's impossible to test this without a predefined (cross-build) test environment, but it's pretty clear what's going wrong from the code itself. So skip the tests if you like, but please apply the fix, so that people don't have to carry around patches for meson.

Thanks!

[ghost]

Seems like someone with commit rights independently fixed it in 11e3011 with the exact same fix, so this can be closed.