Legacy LLVM Version Removal

I’ve opened an issue about removing legacy LLVM versions. I’m sharing the post here to help get everyone on track.

Ref: Legacy LLVM Version Removal · Issue #305146 · NixOS/nixpkgs · GitHub

TLDR: Keeping old LLVM versions introduce bloat and require time to maintain. Removing old versions can make supporting new versions easier. This issue will help figure things out with removing old versions.

4 Likes

Understandable, but sad to see them go.

Might be nice to have legacy toolchains in a separate nix-community flake, so theres not a nixpkgs burden.

1 Like

Yeah, it’s a necessary step to making sure Nixpkgs stays fresh. When I did the consolidation of packages into common files, I ran into a bunch of odd version checks. With the process of figuring out legacy LLVM version removal, we can simplify those Nix files. Simpler Nix files can mean less eval. But this will also mean less work overall in the future.

1 Like

You can just pin nixpkgs to get legacy toolchains.

This falls apart as soon as you need everything to be modern but the toolchain or need it to interact with more modern components (i.e. graphics drivers).

Though, mesa uses llvmPackages_latest so it isn’t a problem.

@wamserma’s idea of pinning nixpkgs and then just importing whatever you need which is legacy could work. However, I don’t want to jump to that immediately. My idea is to add a warning to LLVM versions we wish to remove, would say something like LLVM 12 is marked as deprecated and will be removed in a future version. We would move everything we can off of that version of LLVM and then once the last one or two packages can drop that version, then it is removed.