pkg-config: set pkg-config-rs-compatible env vars

[alyssais]

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.11 Release Notes (or backporting 22.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[yu-re-ka]

I can't really approve of this rust-specific thing being added in all derivations that use pkg-config, even non-rust ones. I also don't disapprove, but for a quick merge you could move this change out of this PR and let me review only the cargo stuff (with that PKG_CONFIG_ variable being set just like in rustc).

[Mic92]

What if it was in the cargo setuphook? Than as soon as you add rustc to a build, you would get it.

[alyssais]

I think the pkg-config wrapper is the right place for this. It's the only place that makes sense that is shared between the rustc build, and all the builds that use Cargo.

Technically, it doesn't have anything to do with pkg-config (since it comes from the pkg-config crate), but it doesn't have anything to do with Cargo either. It's also extremely similar to PKG_CONFIG_FOR_BUILD, defined on the line above, so it makes sense to set both very similar environment variables in one place.

[Ericson2314]

I agree it doesn't go here.

We can have a separate setup hook that Rust. buildRustCrate, buildRustPackage, etc. all use.

[Ericson2314]

rust-lang/pkg-config-rs#139 Also, I opened an issue in the relevant package build.rs file use, so we can nip this in the bud.

[Ericson2314]

It's a small amount of code, but changing it is mass rebuild. So I think about the "mass rebuild" costs of these sorts of things too.

The rebuild could be indirect from changing the toRustTarget stuff too.

[Ericson2314]

Also think how if we do two setup hooks it's easy to combine later, but if we do one setup hook it's hard to split later.

[alyssais]

That would be an extremely rare change to make, especially for the limited set of architectures we actually build for. We do full rebuilds every couple of weeks anyway, so I don't think it's at all worth optimising for avoidance of mass-rebuilds in infrastructural stuff like this. Indeed, avoiding mass rebuilds is how we end up with unnecessary conditionals making maintenance more complicated forever, because it avoided mass rebuilds once. And Rust is so widely used that any change to it is going to cause huge rebuilds anyway, regardless of whether it affects pkg-config.

[alyssais]

And having a separate setup hook just for this (cargoPkgConfigSetupHook?) would mean broken cross packages forever, because since it would only be required for cross, nobody would ever remember to apply it.

[Ericson2314]

If we did this, would we want to put this same logic sort of in bintools-wrapper and cc-wrapper too?

[yu-re-ka]

The first time I looked at this, it was not obvious that PKG_CONFIG_FOR_BUILD is set directly above the newly added code, and that it is autoconf/meson specific.
I now think this might be fine, but would give @Ericson2314 the last word (to change their mind or explain why this is still a bad idea)

[Mindavi]

@Ericson2314 and @alyssais, what would be a good way to move this forward? I do kinda agree that it feels wrong to modify the pkg-config wrapper, if a hook were to be added, could that be added to buildRustPackage or injected when cargo or rust is added? Then there might be less of a need to remember to add it.

[alyssais]

@Ericson2314 and @alyssais, what would be a good way to move this forward? I do kinda agree that it feels wrong to modify the pkg-config wrapper, if a hook were to be added, could that be added to buildRustPackage or injected when cargo or rust is added? Then there might be less of a need to remember to add it.

I asked John to expand on his most recent comment on Matrix, and AIUI we're still waiting for him to find the time to talk it through with me.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/unable-to-build-pkgsstatic-gcc/27795/6

[K900]

LGTM, we discussed this a bit on Matrix earlier.

[emilazy]

We may be able to drop PKG_CONFIG_ALLOW_CROSS now. It will mean that targets without a pkg-config dependency will fail to use pkg-config and maybe fall back to non‐pkg-config methods, but that’s at least consistent with the non‐cross behaviour. Otherwise it will run plain pkg-config when there isn’t a variable for the appropriate target, because we set PKG_CONFIG_ALLOW_CROSS, and that seems bad.

The other alternative is setting PKG_CONFIG_SYSROOT_DIR per target and using one pkg-config, but I think our wrappers don’t work well with that at present?

[alyssais]

Will need to do some more testing with this — it turns out that Cargo cross compiles correctly without any workarounds even without this change, so I didn't catch that this wasn't actually doing anything! Need to find another test case.