Alyssa Ross ecc1ec2c72 llvmPackages_latest: move to aliases.nix ... Because llvmPackages_latest is used in Nixpkgs, by quite a few packages, it's difficult to keep it up to date, because updating it requires some level of confidence that every package that uses it is going to keep working after the update. The result of this is that llvmPackages_latest is not updated, and so we end up in the situation that "latest" is two versions older than the latest version we actually provide. This is confusing and unexpected. "But won't this end up fragmenting our LLVM versions, if every package previously using _latest is separately pinned to LLVM 14?", I hear you ask. No. That fragmentation is already happening, even with an llvmPackages_latest, because packages that actually require the _latest_ version of LLVM (15/16), have already been decoupled from llvmPackages_latest since it hasn't been upgraded. So like it or not, we can't escape packages depending on specific recent LLVMs. The only real fix is to get better at keeping the default LLVM up to date (which I'm reasonably confident we're getting into a better position to be feasibly better able to do). So, unless we want to double down on providing a confusingly named "llvmPackages_latest" attribute that refers to some arbitrary LLVM version that's probably not the latest one (or even the latest one available in Nixpkgs), we only have two options here: either we don't provide such an attribute at all, or we don't use it in Nixpkgs so we don't become scared to bump it as soon as we have a new LLVM available.		2023-05-08 13:05:33 +00:00
..
0001-Remove-unused-function-after_eq.patch
conf-symlink.patch
default.nix	llvmPackages_latest: move to aliases.nix	2023-05-08 13:05:33 +00:00