swig: swig3 -> swig4

[bcdarwin]

Description of changes

Bumps the default version of swig.

Modest but nonzero breakage expected.

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/)
• 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.

[emilazy]

Thanks for this! Going to figure out a test build to run to make sure this ~basically works before merging.

[emilazy]

I rebased this onto master locally and came up with this rough, likely partially‐incorrect list of most of the direct dependencies of swig with a naive grep and trimming stuff that was wrong or wouldn’t build on aarch64-linux:

[emily@aarch64:~/nixpkgs]$ NIXPKGS_ALLOW_UNFREE=1 nix run nixpkgs#nix-output-monitor -- build --keep-going -f . apfel audit autodock-vina codec2 comedilib cvc4 dtc fastnlo-toolkit gdal gdalMinimal gforth gnucash gsm hamlib_3 highlight kodi kodi-gbm kodi-wayland libdnf libftdi libnl libnvme libratbag libredwg libselinux libsemanage libyafaray mapserver mlt mupdf mypaint mysql-workbench nnpdf openmm partio pjsip plfit proot python3Packages.catboost python3Packages.faiss python3Packages.fenics python3Packages.hfst python3Packages.htseq python3Packages.ifcopenshell python3Packages.ihm python3Packages.lightgbm python3Packages.m2crypto python3Packages.marisa python3Packages.marisa-trie python3Packages.mecab-python3 python3Packages.meep python3Packages.pc-ble-driver-py python3Packages.pivy python3Packages.py-slvs python3Packages.pybox2d python3Packages.pycdio python3Packages.pygsl python3Packages.pymupdf python3Packages.pyscard python3Packages.pyunbound python3Packages.sigrok shogun snagboot trilinos trilinos-mpi volume_key zeek babeltrace2 freecad libsbml openturns trexio unbound llvmPackages.lldb swift libsForQt5.libopenshot --impure --show-trace

It’s ~1,000 builds, which is not too bad. Let’s see how it goes overnight.

[emilazy]

Successfully built the following on aarch64-linux:

apfel
audit
autodock-vina
babeltrace2
codec2
comedilib
cvc4
dtc
fastnlo-toolkit
freecad
gdal
gdalMinimal
gforth
gnucash
gsm
hamlib_3
highlight
kodi
kodi-gbm
kodi-wayland
libdnf
libftdi
libnl
libnvme
libratbag
libredwg
libsForQt5.libopenshot
libsbml
libselinux
libsemanage
libyafaray
llvmPackages.lldb
mapserver
mlt
mupdf
mysql-workbench
nnpdf
openmm
openturns
partio
pjsip
plfit
proot
python311Packages.pivy
python3Packages.catboost
python3Packages.faiss
python3Packages.fenics
python3Packages.hfst
python3Packages.htseq
python3Packages.ihm
python3Packages.lightgbm
python3Packages.m2crypto
python3Packages.marisa
python3Packages.marisa-trie
python3Packages.mecab-python3
python3Packages.meep
python3Packages.pc-ble-driver-py
python3Packages.py-slvs
python3Packages.pybox2d
python3Packages.pycdio
python3Packages.pygsl
python3Packages.pyscard
python3Packages.pyunbound
python3Packages.sigrok
snagboot
trexio
trilinos
trilinos-mpi
unbound
volume_key
zeek

I didn’t see any obvious regressions from Hydra. python3Packages.pymupdf fails building a MuPDF with SWIG stuff enabled, but that already happens on master. I also successfully built gdal on aarch64-darwin.

I think this is good to land; thank you! The next cycle will probably be in a couple of weeks. If you want to get involved in pinning anything that happens to break, malob’s status pages can be useful and I’d suggest joining the Staging room on Matrix, but since it looks like this should be an uneventful bump I’m sure we can handle it with our existing resources.

Given the complete lack of regressions here so far, it seems like removing swig3 is in sight, if we can do something about old LLDBs and Gforth. I think dropping support for old versions of LLDB should be okay, as it’s not part of the core LLVM compiler toolchains and it should presumably be reasonably backwards‐compatible. No idea about Gforth, but since it uses a fork anyway, if it becomes the last remaining user we could probably just move the swig3 derivation into its directory…

[emilazy]

@bcdarwin The staging-next cycle was merged, and if there were any regressions caused by this we didn’t notice them :) Hopefully we can get rid of swig3 soon.

[bcdarwin]

@emilazy first attempt at removing from gforth is up in #341230.

Unfortunately, I'm also trying to sneak an unstable SWIG into tree via #337775.