Nixpkgs: LLVM 4.0 coming soon!

[dtzWill]

Issue description

According to the 4.0 release schedule, they're aiming to wrap up the final 4.0 in ~11 days:

Release schedule (from http://llvm.org):

• Jan 12, 2017: Branch; RC1 soon after.
• Feb 1: RC2 tag.
• Feb 21: Final tag; release soon after.

I think mostly we just need to copy things over from 3.9--
in my local tree I track LLVM trunk and have been using the same expressions since before 3.9 although I'm only testing with my own use cases, not all of Nixpkgs.

Anyway, hopefully it's easy to get the RC packaged and get ahead of any potential problems before the official release is made.

Steps to reproduce

Technical details

• System: (NixOS: nixos-version, Ubuntu/Fedora: lsb_release -a, ...)
• Nix version: (run nix-env --version)
• Nixpkgs version: (run nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion)

[copumpkin]

Damn, I need to dust off my Darwin LLVM upgrade. I couldn't bear to still have Darwin on 3.7 while 4.0 is the latest and greatest. Thanks for the new motivation 😄

[vcunat]

There's some SVN version on #20454, but the copying approach makes it harder to see what was actually changed.

[dtzWill]

Oh, awesome! I agree with @corngood about the organization and code duplication getting out of hand with LLVM but wasn't sure I had enough time myself to tackle it so wasn't going to say anything O:).

But +1 for approaches in that direction and I'd be happy to help contribute best I can (I have a few abstractions locally that are maybe useful, maybe not :)) to make this happen.

On the subject of LLVM-wishlists: what do you folks think about building LLVM as one big project and splitting it up into multiple outputs?

Standalone building of LLVM projects is a bit of a low-priority in my experience, frequently breaking and just generally not being tested nearly as much as the build-all-the-things approach.

While it would be unfortunate to build too many components, we could a)make them optional even in the unified build or b)hope most people use binary caches and so only need to grab the components they are asking for anyway.

In my mind the biggest potential problem with this approach is whether we can (easily) split apart the various components in a way that works as LLVM expects and without unnecessary references/dependencies between components.

I bring this up, because in my own local build this is the approach I take as standalone building is especially unsupported when you're chasing the latest trunk and I'm building all the projects anyway :).

Thoughts? :)

[vcunat]

We have 4.0rc2 in master. It's copy-edit as usual, but I guess we can close this.

[copumpkin]

Darwin is now using 4 by default (as of earlier today in staging)

[andrewrk]

thanks everyone for getting 4.0rc2 up even before 4.0.0 final was released. That was a lovely surprise. I was hoping we could do something similar for 5.0.0, scheduled to be released aug 23 (1 week from now)

[copumpkin]

Make a ticket 😄 I'm generally not very experienced with packaging it, but know a thing or two about bumping the Darwin stdenv to use it.

[andrewrk]

I'll work on a PR. Takes half a day to do the test compilation though

[copumpkin]

Oh yeah, that's miserable 😦