Legacy LLVM Version Removal

[RossComputerGuy]

As new versions of LLVM come out and get packaged, the amount of LLVM versions we have in Nixpkgs grows. This means more maintenance and work to upkeep older versions. However, if we were to cap the number of LLVM versions we would support then this would mean less work. Though there are challenges as many different things in Nixpkgs depends on different LLVM versions. At the time of writing, we have versions 12, 13, 14, 15, 16, 17, 18, and the git versions. Git will never be removed as it is essentially a testbed for new versions and I use it for proactively updating. LLVM 19 comes out some time in June according to their tracker. When 19 comes out, we would have 8 specific versions of LLVM.

This issue will open the discussions on figuring out the proper procedures of removing legacy versions of LLVM.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/legacy-llvm-version-removal/43666/1

[reckenrode]

The plan for Darwin going forward is to do annual updates to whatever is the latest after the x.05 release. The goal is not to be stuck on the trailing edge of LLVM support as Darwin was in the past.

[RossComputerGuy]

Been told Haskell's latest supported LLVM version is 16.

[Atemu]

Note that there are multiple versions of GHC in Nixpkgs but I don't know whether they're maintained to any official capacity. cc @sternenseemann @cdepillabout

As for maintenance: Would it perhaps be possible to bundle older versions of LLVM into a legacy derivation that is "maintained" (or rather not maintained very much) separately from the primary derivation for modern LLVM? Or simply keep the separate files for the old versions that we currently have and only integrate modern versions into the new generic derivation.
I don't know how maintenance-intensive the old versions are though. Do they require frequent maintenance or could you just declare them as legacy and not improve them in any way other than critical bug fixes? (How often would those be necessary?)

That way we could have a modern and maintainable LLVM drv while those depending on older versions of LLVM could still use the legacy derivations. They wouldn't be improved in any way but they will likely just continue working as they always have.

[RossComputerGuy]

As for maintenance: Would it perhaps be possible to bundle older versions of LLVM into a legacy derivation that is "maintained" (or rather not maintained very much) separately from the primary derivation for modern LLVM? Or simply keep the separate files for the old versions that we currently have and only integrate modern versions into the new generic derivation

Alternatively, we could add a warning saying that the LLVM version is deprecated. Once every package is moved away from that version, we can remove it.

I don't know how maintenance-intensive the old versions are though. Do they require frequent maintenance or could you just declare them as legacy and not improve them in any way other than critical bug fixes? (How often would those be necessary?)

They do not require much. However after the commonification PR's, every subpackage gets a common Nix file. This means there's a lot of version checks. If we're able to deprecate certain versions then we can remove those specific version checks. This would be less evaluation and less code to manage overall. My concern is unnecessary rebuilds and ending up with Nix files that have a ton of version checks.

[cdepillabout]

cc all of @NixOS/haskell for the ghc/llvm stuff

[Atemu]

However after the commonification PR's, every subpackage gets a common Nix file. This means there's a lot of version checks. If we're able to deprecate certain versions then we can remove those specific version checks. This would be less evaluation and less code to manage overall. My concern is unnecessary rebuilds and ending up with Nix files that have a ton of version checks.

If that's the only concern, the option I described would also be sufficient; keep the old versions in separate files as they are right now and only attempt to commonise the latest versions.

The legacy versions won't get any of the improvements of the common drv but they're legacy anyways so nobody expects them to improve or change in any way.

[Atemu]

One thing I forgot to mention is that my intention is merely to present this idea as an alternative because it didn't seem to have been considered. I'm only slightly in favour of it and don't have a horse in this race; if you think that's not feasible, that's completely fine by me.

The reason I'm slightly in favour is just that IME having old versions around can be really valuable at times, so I generally like keeping stuff for as long as it doesn't cause an actual maintenance burden.

[reckenrode]

GCC in nixpkgs supports all the way back to 4.8. Is there anything it’s doing that might be useful for LLVM? It has many version checks, but there are helpers to make them nicer to use.

[RossComputerGuy]

If that's the only concern, the option I described would also be sufficient; keep the old versions in separate files as they are right now and only attempt to commonise the latest versions.

The commonification of LLVM is already done and I don't want to split things up into a legacy set of things because of redundancy.

The reason I'm slightly in favour is just that IME having old versions around can be really valuable at times, so I generally like keeping stuff for as long as it doesn't cause an actual maintenance burden.

Yeah, though people can import older versions of Nixpkgs if they really want an ancient version of a package. Anything critical to Nixpkgs, we can do extra stuff for if they really need to be on an old version of LLVM.

GCC in nixpkgs supports all the way back to 4.8.

As GCC is needed for literally everything in Nixpkgs, I think that GCC having versions that old makes sense. However, LLVM does not have as many dependent packages.

[reckenrode]

As GCC is needed for literally everything in Nixpkgs, I think that GCC having versions that old makes sense. However, LLVM does not have as many dependent packages.

But would how it does that be useful or applicable to LLVM? That’s why I brought it up. If the preference is not to maintain older version support regardless, that’s understandable.

[RossComputerGuy]

But would how it does that be useful or applicable to LLVM? That’s why I brought it up. If the preference is not to maintain older version support regardless, that’s understandable.

I'm not sure how GCC is in Nixpkgs, depending on how it is set up then I might prefer going that route.