Prune unused/unneeded/old versions of llvm

[dezgeg]

We have 8 versions of LLVM currently:

llvm_34
llvm_35
llvm_37
llvm_38
llvm_39
llvm_4
llvm_5
llvm_6

Let's get rid of the older ones where possible.

[vcunat]

So... we delete all unreferenced versions (after some time) and then see if someone minds? Is there some other way to find which are likely to be useful?

[jtojnar]

See also #30229

[vcunat]

One alternative might be to at least not (re)building all of them on Hydra all the time, but in any case I'd try to find at least a couple to remove completely.

[copumpkin]

Huge 👍to this. How much I mind old versions for me is roughly proportional to how long the builds are (if they all take 5 seconds, I don't really care) and how much duplicated code there is between them (LLVM is an awful offender here). As someone who often needs changes to LLVM because of its integration with the Darwin stdenv, old versions of LLVM have been the bane of my existence.

[RaitoBezarius]

LLVM5:

• Cling: interactive C++ interpreter cling: update to 0.9 #202114
• Mozart: Implementation of the Oz programming language: mozart: use llvmPackages_8 instead of llvmPackages_5 #224639
• python39Packages.llvmlite: older versions of the Python package

LLVM6

• emacs in withMacports = true;: @NixOS/emacs could you enlighten us?
• python39Packages.llvmlite: older versions of the Python package

LLVM7

• mrustc: needs update; latest version uses LLVM 12
• ghc884: @NixOS/haskell do we need this attr?

[adisbladis]

emacs in withMacports = true;: https://github.com/orgs/NixOS/teams/emacs could you enlighten us?

I don't have a short and sweet explanation, but more context can be found at #127902.

[RaitoBezarius]

emacs in withMacports = true;: https://github.com/orgs/NixOS/teams/emacs could you enlighten us?

I don't have a short and sweet explanation, but more context can be found at #127902.

It seems like a packaging mistake: UniformTypeIdentifiers/UniformTypeIdentifiers.h seems to come from a macOS framework: UniformTypeIdentifiers.framework.
The patch mentioned here: #127902 (comment) seems to fix the compilation issue and let us drop the old LLVM requirement I believe.

Of course, it may not fix the underlying issue.

[RaitoBezarius]

@progval @r-burns What would it take to bump mrustc to use LLVM12? I am fine with bumping it to a unstable version (to target something like Rust 1.54.0 for example).

[maralorn]

According to ghc docs https://downloads.haskell.org/ghc/8.8.4/docs/html/users_guide/8.8.1-notes.html#llvm-backend ghc 8.8 is only compatible with LLVM 7. We have not yet decided to drop 8.8.4, yet. So until then, I think it’s best llvm 7 stays.

Otoh @sternenseemann might have more insight.

[RaitoBezarius]

According to ghc docs https://downloads.haskell.org/ghc/8.8.4/docs/html/users_guide/8.8.1-notes.html#llvm-backend ghc 8.8 is only compatible with LLVM 7. We have not yet decided to drop 8.8.4, yet. So until then, I think it’s best llvm 7 stays.

Otoh @sternenseemann might have more insight.

Do you have a vision on when 8.8.4 will be deprecated/dropped?

[progval]

@RaitoBezarius the latest mrustc tag (v0.10) supports Rust 1.54.0, which does support LLVM 12.0.0 (not sure about >= 12.0.1 though)

[vcunat]

The patch bumps should be compatible by design.

[RaitoBezarius]

@RaitoBezarius the latest mrustc tag (v0.10) supports Rust 1.54.0, which does support LLVM 12.0.0 (not sure about >= 12.0.1 though)

If you have any time to bump it before the branch off, that would be extremely awesome. :)

[r-burns]

I had some issues with mrustc 0.10 last I tried, but unstable seems to be working okay. I already had a wip bump to unstable, and I was planning to wait until the next mrustc release but I'll go ahead and open a PR later so we can get on rust 1.54 with llvm 12.

[progval]

WIP at #224970

[sternenseemann]

LLVM7

Given that this was the default nixpkgs LLVM version not that long ago, I'm not sure if it is prudent to remove it already. In general it seems to me that a push to remove old stuff just for the sake of it is just annoying busywork that usually only has the tangible result of annoying downstream users.

I do not think that removing old versions of LLVM helps us with refactoring the LLVM expressions. Only unifying all LLVM >= 8 expressions is already an incredibly big task. I'd rather recommend having a common expression going forward, i.e. git, 15, 16, … that we continuously update to also support whatever new version comes out.

That being said, GHC 8.8.4 is not strictly needed anymore from a nixpkgs perspective, i.e. it is neither used for bootstrapping nor required by any specific package, but there is also no particular reason to remove it either.

[RaitoBezarius]

Dropping LLVM 5 & 6 for NixOS 23.11.
We can explore LLVM 7 drop for NixOS 24.05 or 24.11 depending on the situation.
In #264364

[RaitoBezarius]

Dropping only LLVM 5 because GHC 8.6.5 depends on LLVM 6…

[rrbutani]

See: #283954, #305146.