cargo.bbclass: invoking pkg-config for host-crates while building a target recipe will lead to host/target mismatch

[codyps]

Just to clarify the items in play here (because the title is a disaster).

A. target recipe using cargo: a bitbake recipe that invokes cargo to build, and is being built for the bitbake target (ie: not native).
B. crate using calling/using pkg-config and being built for the host (say, for a plugin or the build script)
C. crate being built for bitbake target (which may use pkg-config).

A contains C & B. C's build script (or similar) depends on B.

If a recipe for a target package that calls cargo (A) has cargo host-dependencies that use pkg-config to find host-libraries (B), B's calls to pkg-config will discover TARGET libraries instead of HOST (ie: native.bbclass) libraries, and likely fail to build (or potentially take some other action like trying to build the library locally instead of using bitbake's provided version).

It seems like fixing this will likely mean getting some modifications to the pkg-config crate so that we can supply different PKG_CONFIG_PATHs for host vs target builds, probably by using similar logic to gcc-rs for the environment variables.

Right now running into this appears unlikely (I'm not aware of any examples) because most build scripts are fairly simple. I'm worried that increased use of plugins may increase the complexity of the things cargo builds for host, which would increase the likely hood of hitting this issue.

I haven't yet run into this, just wanted to make sure it's on our radar.