This is very useful in conjunction with meta.pkgConfigModules, as the
new tester can use the list provided by this meta attribute as a default
value for moduleNames, making its usage in passthru.tests very
convenient.
For backwards compatibility, a shim under the old name is maintained
with a warning.
Currently the throw codepath will never be hit. Specifically it doesn't
guard against a misuse of the hook:
pkgsCross.aarch64-multiplatform.mesonEmulatorHook # this should fail
pkgsCross.aarch64-multiplatform.buildPackages.mesonEmulatorHook # this should (and does) succeed
The check sort of worked to guard against use in situations where the
hook wasn't misplaced between nativeBuildInputs and buildInputs, but
the build platform was actually able to execute binaries built for the
host platform.
This worked because nativeBuildInputs would first of all need to
evaluate pkgsHostTarget.mesonEmulatorHook in order to access the spliced
derivation it wants, pkgsBuildHost.mesonEmulatorHook. For this, you'd
need to pass the if expression, at which point buildPlatform and
targetPlatform would match the build and target platform of the
derivation that uses the hook. Consequently the check is “correct”,
since it is its build platform that needs not to be able execute stuff
built for its host platform.
The target platform is technically wrong here, but it works out
since (at least currently) in nixpkgs either build and host or host and
target platform are equal. When doing the check in pkgsHostTarget,
target and host platform are equal.
However, this is a kind of incomprehensible rube goldberg machine, let's
some mistakes slip through the cracks and relies on implementation
details of splicing.
To alleviate this, we do the following:
- We move the check _into_ the derivation. By doing the check when
obtaining the file for the setup hook and not before calling
`makeSetupHook`. This means that we can force `mesonEmulatorHook`
even if forcing `mesonEmulatorHook.outPath` would throw. This ensures
that splicing can work even if the some of the derivation variants
would fail to evaluate.
- Since splicing works now, we can no longer have to do the check
“globally” before splicing happens. This means we can use the setup
hook derivation's own platforms. buildPlatform is irrelevant here,
since this is only the platform on which the shell script is put
together. hostPlatform matters, since it is were the setup hook is
executed later (i.e. the using derivation's build platform). target
platform is the platform the adjacent meson builds executables for,
i.e. the platform we may need to emulate for.
To verify this change, I have evaluated all derivations using
mesonEmulatorHook in `pkgsCross.aarch64-multiplatform` before and after
this change. The hashes don't change.
