wayland: don't propagate bin output

[flokli]

This fixes the host platform wayland-scanner binary leaking into cross builds.

Fixes pkgsCross.aarch64-multiplatform.glfw for example.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux (via pkgsCross from x86_64)
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• 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/)
• 24.11 Release Notes (or backporting 23.11 and 24.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.

---

Add a 👍 reaction to pull requests you find important.

[alyssais]

TIL propagatedBuildOutputs!

I should really finish #214906 …

[SomeoneSerge]

On a more general note:

• This should maybe exclude "binaries":

  nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh

  Lines 195 to 197 in db5bef9

  	# Default value: propagate binaries, includes and libraries
  	if [ -z "${propagatedBuildOutputs+1}" ]; then
  	local po_dirty="$outputBin $outputInclude $outputLib"

• It's often awkward we cannot get headers (which we put into .dev) separately from propagatedBuildOutputs. In this case it was an issue for cross-compilation. Another instance where I encountered this is when I wanted to build scipy against numpy_2 and propagate numpy (<2) for wider compatibility

[flokli]

Added the comment, and re-targeted to staging.

[trofi]

Bisect says the change broke gst_all_1.gst-plugins-base in staging as:

$ nix build --no-link -f. -L gst_all_1.gst-plugins-base
...
gst-plugins-base> Program wayland-scanner found: NO
gst-plugins-base> gst-libs/gst/gl/meson.build:674:8: ERROR: Problem encountered: Could not find requested Wayland libraries

[flokli]

Thanks for the ping, will take a look.

[flokli]

Fix in #329452. Will quickly check all other gst packages.

[emilazy]

It should be possible to re‐apply this now that @paparodeo’s work in #318226 has landed in staging.

[SomeoneSerge]

It should be possible to re‐apply this now

It shouldn't be necessary

[SomeoneSerge]

In fact, I think we should maybe remove the custom .pc from $bin, and also maybe even delete wayland-scanner = wayland.bin from the package set. The dev in nativeBuildInputs propagating bin should now work perfectly fine, so it is with wayland-scanner.pc. We'd just write nativeBuildInputs = [ wayland ]; buildInputs = [ wayland ]; to get both the scanner and the libraries

[alyssais]

That causes its own problems, see #214895.

But there's no overlap really between wayland and wayland-scanner, so the best thing to do is probably to have it as a completely separate package: #214906

[SomeoneSerge]

Thanks @alyssais I didn't know about this one. A separate derivation sounds even better

[alyssais]

(If anybody wants to take over that PR please do — the main thing that was hard about it was checking there were no cross regressions, but tbh mostly I think I got distracted by trying to fix packages that didn't cross compile anyway! I don't know when I'll have time to pick it back up now.)