haskellPackages.cabal-install: fix build when cross compiling

[alexfmpe]

Fixes nix-build -A pkgsCross.aarch64-multiplatform.haskellPackages.cabal-install

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[alexfmpe]

This causes rebuild even on the native case due to the extra exec.
One way to get around it is something like

let emulatorIfNeeded exe = if isCross then (emulator + " " + exe) else exe;

and then

${emulatorIfNeeded ''"$out/bin/cabal"''} man --raw > "$out/share/man/man1/cabal.1"

[wolfgangwalther]

Why do we even call $out/bin/cabal here? Shouldn't we call the build tool cabal in this case?

[alexfmpe]

Not sure, maybe @sternenseemann remembers?
They seem to have the same output, as
diff result-cabal-native/share/man/man1/cabal.1.gz result-cabal-cross/share/man/man1/cabal.1.gz came out empty.
I can't imagine a non-contrived scenario where they would differ. The only real concern I see is that build tool cabal might be a different version.
Tangent, but I think we might end up using this "run executable via emulator" logic quite a bit for those test suites which expect the executable in PATH

[wolfgangwalther]

It was introduced in #115347. It doesn't look like it was on purpose that way.

[sternenseemann]

Cabal doesn't act as a build tool that generates a man page from source files here. Rather, it dumps its own documentation that is compiled in. Hence it is correct to use $out/bin/cabal (it just is an ill-conceived mechanism). In particular, cabal-install doesn't even depend on cabal-install at build time and if we would introduce this dependency, there would not be a guarantee that the output would be the same, i.e. running cabal man and man cabal would give different results.

My vote would be to just disable the man page generation if cross compiling. There is no good way to support this.

[sternenseemann]

Tangent, but I think we might end up using this "run executable via emulator" logic quite a bit for those test suites which expect the executable in PATH

Also here, probably disabling is better. The emulator is not a silver bullet (e.g. the user space qemu can't inject itself into exec calls) and also not necessarily available.

[wolfgangwalther]

Thanks for clarifying.

My vote would be to just disable the man page generation if cross compiling. There is no good way to support this.

Agreed.

[alexfmpe]

My vote would be to just disable the man page generation if cross compiling. There is no good way to support this.

Even for pkgsStatic ?
What about disabling when canExecute is false, which is what actually requires emulator shenanigans?

[wolfgangwalther]

What about disabling when canExecute is false

Yes, that.