@DieGoldeneEnte the downloading part seems to work, cmake still has trouble. See last commit message. Feel free to iterate on this or suggest a better way :-)

I would suggest waiting a little, maybe the tarballs will be added later (I think the source-code archives are auto-generated). Someone already asked for the usual tarballs (http://lists.llvm.org/pipermail/llvm-dev/2020-May/141684.html).
Also I think it is better to not split the source-archive. If you split it up you will get 2 copies in your nix-store and since there are a lot of dependencies between the different tools you still get a good amount of rebuilds (I think everything depends on llvm and it gets updated multiple times a day).
I would need to take a closer look to get an overview of the differences when building with the mono-repo.

Well, having such a monorepo-style thing would help tracking master, but that probably has a very limited audience.

@ggreif I agree, the mono-repo is the right way (also to track other llvm-repositories like the one from amd).
I think the best way wouldbe to just use the same source (the complete one) for all the tools. It might be useful to separate smaller components not depending on llvm, like libunwind, but for the large components like clang this is not as useful (for development use one could still give a separate source for the component in question).

Okay, the split tarballs arrived. Updating...

@GrahamcOfBorg build llvm_10 clang_10 lldb_10 lld_10 llvmPackages_10

The only problem I see is #87528. So this is ready for review.

LGTM. It builds and I didn't have any problems with small test compilations.
I checked the llvm-patch. The canges are still only in master and not included in this version.

Edit: It should be squashed before merging :)

Result of nixpkgs-review pr 88248 1

@Mic92 Thanks for doing this! Do you get different results with 10.0.0? (It is okay to say "don't know" then I'll try it locally.)
Hey, I just tried, with shards giving me this tail:

CMake Generate step failed.  Build files cannot be regenerated correctly.
builder for '/nix/store/vm1zqvr0rcjy83a2qg2xnhxix76122mn-compiler-rt-10.0.1rc1.drv' failed with exit code 1
cannot build derivation '/nix/store/8pwnwbb3w53jxdlw0swy1wcp7ynr2444-clang-wrapper-10.0.1rc1.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/xnadl4s96ffznb4gcxj84p5gnywxap3a-crystal-0.34.0.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/x8vprmg4w9xaxpdjj68dl6wvg2680sxy-shards-0.10.0.drv': 1 dependencies couldn't be built
error: build of '/nix/store/x8vprmg4w9xaxpdjj68dl6wvg2680sxy-shards-0.10.0.drv' failed

I bet this is #87528. When will that be out of staging?

This is the result I get with nixpkgs-review pr 88248 I only have 3 fails:

4 packages failed to build:
google-cloud-cpp python37Packages.tiledb python38Packages.tiledb scry

25 packages built:
ameba bat-extras.prettybat chromium clang-tools clang_10 crystal crystal2nix crystal_0_31 crystal_0_32 crystal_0_33 embree2 gitAndTools.thicket icr ispc lld_10 lldb_10 llvm_10 lucky-cli luxcorerender mint oq shards tiledb tinygo zig

on a x86_64 system.
The tiledb-fails are because of tests, previously these had nothing to do wit the compiler.
google-cloud-cpp fails on master also (with clang 10.0.0). and seems to be unrelated to llvm.

This is the result I get with nixpkgs-review pr 88248 I only have 3 fails:

4 packages failed to build:
google-cloud-cpp python37Packages.tiledb python38Packages.tiledb scry

25 packages built:
ameba bat-extras.prettybat chromium clang-tools clang_10 crystal crystal2nix crystal_0_31 crystal_0_32 crystal_0_33 embree2 gitAndTools.thicket icr ispc lld_10 lldb_10 llvm_10 lucky-cli luxcorerender mint oq shards tiledb tinygo zig

on a x86_64 system.
The tiledb-fails are because of tests, previously these had nothing to do wit the compiler.
google-cloud-cpp fails on master also (with clang 10.0.0). and seems to be unrelated to llvm.

In doubt I would trust this result more. I don't have a nix-daemon running on this machine, so there might be subtle bugs.

TODO:

patching sources
applying patch /nix/store/kavpkf622k44kw6j7hs40b4zchx116g4-llvm-extension-handling.patch
patching file CMakeLists.txt
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file CMakeLists.txt.rej
patching file cmake/modules/AddLLVM.cmake
Hunk #1 FAILED at 884.
1 out of 1 hunk FAILED -- saving rejects to file cmake/modules/AddLLVM.cmake.rej
patching file cmake/modules/CMakeLists.txt
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file cmake/modules/CMakeLists.txt.rej

@DieGoldeneEnte we still have the manpages problem. Any ideas what they could be?

Sorry, somehow forgot to mention it here.
The problem is with recommonmark and sphinx3 not working nicely together (see #93117).

To test building you can revert ./pkgs/development/python-modules/sphinx to commit 84cf00f.

See 2a5899b (and parent) for how to revert to candidates.

FYI recommonmark is marked as broken for now (on master). As a result llvmPackages 8-10 can't be build completely (manpages for llvm fail). Older versions are not affected, because they don't use recommonmark.

I think we can remove (comment out) the llvm manpages for 8 until 10 (and the lldb for 10) since it can't be viewed with man anyways.

What do you think @ggreif @matthewbauer ?

@DieGoldeneEnte I am okay with that, since you can read the manpages on the internet anyway. Do you want to add a commit?

I'll open an other PR so I can disable them all in one commit.
They still merge automatically :)

Edit: #94061