wesnoth: fix darwin and LLVM 19 compatibility

[niklaskorz]

LLVM 19 removed support for types not officially supported by std::char_traits: https://libcxx.llvm.org/ReleaseNotes/19.html#deprecations-and-removals
Wesnoth relies on this previously supported non-standard behavior for some types that should either have been a vector or span: wesnoth/wesnoth#9546
Unfortunately we can't just use std::span as that requires C++20, and making Wesnoth C++20 compatible is a non-trivial problem.
As a workaround, we make use of gsl-lite, which includes a lightweight implementation of span.
I've applied the relevant commits from 1.19 that wrap boost::span, and kept my own patch for fixing the lightmap (see comment above the patch).

Furthermore, while this package built on darwin before Clang 19 landed, it didn't run, as Wesnoth requires the binary to be contained in a macOS app bundle to function. This is also fixed in this PR by manually creating the app bundle using the upstream resources and Info.plist.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • 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/)
• 25.05 Release Notes (or backporting 24.11 and 25.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.

[Samasaur1]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 381227

---

x86_64-darwin

✅ 1 package built:

• wesnoth (wesnoth-dev)

---

aarch64-darwin

✅ 1 package built:

• wesnoth (wesnoth-dev)

[Samasaur1]

Looks good to me. I did notice that this won't support nix run, and I have seen some macOS app PRs recently that add a little shim in $out/bin that launches the app. Up to you whether you want to include one or not — I suspect that it's rare for anyone to try to nix run this package anyway

[emilazy]

I’m a little worried about the patch that upstream presumably wouldn’t accept. Can we do something that doesn’t pull in another dependency?

[viraptor]

Since this is llvm-19 specific, can we do a more precise version check here? Since nixpkgs allows using both earlier and later versions, it may be nicer to only apply this for llvm19+

[niklaskorz]

Fair enough, will do!

[niklaskorz]

I’m a little worried about the patch that upstream presumably wouldn’t accept. Can we do something that doesn’t pull in another dependency?

The upstream solution would be adopting C++20 imho, which is a bit beyond the scope of this PR. The only other alternative I see would be to vendor an even more lightweight implementation of span than gsl-lite, e.g. https://github.com/martinmoene/span-lite (which is also packaged in nixpkgs already), but I'm generally more confident in using gsl-lite as it's more widely used and more actively maintained.

Upstreaming this fix could use my changes as a starting point, but replacing gsl-lite with C++20's std::span and then going from there to fix all other incompatibilities with C++20.

[niklaskorz]

Looks good to me. I did notice that this won't support nix run, and I have seen some macOS app PRs recently that add a little shim in $out/bin that launches the app. Up to you whether you want to include one or not — I suspect that it's rare for anyone to try to nix run this package anyway

That's a good idea, it might not be the most frequent way to access it but is nice for quickly trying out an app without installing it. I originally wanted to symlink the app's MacOS dir to bin, but that's not sufficient for the binary to locate the app bundle.

[azuwis]

Something like this should make nix run works:

nixpkgs/pkgs/by-name/mo/moonlight-qt/package.nix

Line 79 in 9cbd33c

ln -s $out/Applications/Moonlight.app/Contents/MacOS/Moonlight $out/bin/moonlight

[Samasaur1]

Looks good to me. I did notice that this won't support nix run, and I have seen some macOS app PRs recently that add a little shim in $out/bin that launches the app. Up to you whether you want to include one or not — I suspect that it's rare for anyone to try to nix run this package anyway

That's a good idea, it might not be the most frequent way to access it but is nice for quickly trying out an app without installing it. I originally wanted to symlink the app's MacOS dir to bin, but that's not sufficient for the binary to locate the app bundle.

I think the approach that would work is a script that runs open -na "$(realpath "$out/Applications/The Battle for Wesnoth.app")"

[niklaskorz]

Rebasing and applying wesnoth/wesnoth#10102 right now

[niklaskorz]

Looks good to me. I did notice that this won't support nix run, and I have seen some macOS app PRs recently that add a little shim in $out/bin that launches the app. Up to you whether you want to include one or not — I suspect that it's rare for anyone to try to nix run this package anyway

That's a good idea, it might not be the most frequent way to access it but is nice for quickly trying out an app without installing it. I originally wanted to symlink the app's MacOS dir to bin, but that's not sufficient for the binary to locate the app bundle.

I think the approach that would work is a script that runs open -na "$(realpath "$out/Applications/The Battle for Wesnoth.app")"

Added, but without the realpath as the app bundle itself is no symlink

[niklaskorz]

I’m a little worried about the patch that upstream presumably wouldn’t accept. Can we do something that doesn’t pull in another dependency?

The additional dependency has been removed as upstream now automatically uses either std::span (for C++20), boost::span (for boost >= 1.78) or a vendored fallback (not relevant for us as we provide boost 1.86 to wesnoth). And before you ask... yeah, I could've used boost::span in my original patch instead of gsl-lite but wasn't aware that boost ships an implementation of span now.

When 1.20 is out, the patches can be removed entirely as upstream's 1.19 branch already includes all required fixes.

[niklaskorz]

Rebased because of the tree-wide removal of obsolete darwin frameworks in #398707