mesonEmulatorHook: make error message agree with code

[ghost]

Description of changes

This commit fixes the error thrown by mesonEmulatorHook so it agrees with the actual condition that was not met.

Discovered during this discussion:

#238331 (comment)

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/)
• 23.11 Release Notes (or backporting 23.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
• Fits CONTRIBUTING.md.

[sternenseemann]

I believe this message is actually correct in a sense—that is the code you'd use at the call site and the hook (which goes in nativeBuildInputs) comes from the previous set.

What should be changed to be totally accurate (but it doesn't matter for any practical case I can think of), is the if— it should be !(stdenv.hostPlatform.canExecute stdenv.targetPlatform) and it should use pkgs, not buildPackages.

[sternenseemann]

I think this works correctly at the moment because

pkgsCross.aarch64-multiplatform.buildPackages.buildPackages.stdenv == pkgsCross.aarch64-multiplatform.buildPackages.stdenv

[ghost]

I believe this message is actually correct in a sense—that is the code you'd use at the call site and the hook (which goes in nativeBuildInputs) comes from the previous set.

Oh I see. Yeah it could be confusing.

We probably shouldn't use the literal stdenv in situations like this where the error message will appear in a scope where stdenv is bound differently than the scope where the error string literal emanates from.

Suggested fix: https://github.com/NixOS/nixpkgs/pull/238654/files#r1239559837