Commit 199b7c50 "compiler-rt: remove <cyclades.h> from libsanitizer"
broke conditional conditional musl patches.
The change has a few effects:
- pkgsStatic.llvmPackages_{5,6,7}.compiler-rt: fix build on musl after cyclades backport
- pkgsStatic.llvmPackages_{{5..13},git}.compiler-rt: drop incomplete musl patches as
sanitizers are disabled anyway and require more upstream porting.
- Drop graalvm8 since it was removed by upstream
- Add update.sh script to make it easier to generate hashes for all
platforms
- Fix GraalPython, broken since #141825 (sorry)
- Small refactorings and fixes
The old "csources" repo has been archived a while ago and a newer
csources_v1 repo has been published. The main advantage is that we now
have support for newer platorms (such as Apple M1's) and newer nim
versions in the bootstrap.
The new repository doesn't contain release tags thus I pinned it to the
latest revision that has been published.
Only adding support for graalvm11-ce. While there is a graalvm8 release
for aarch64-linux, it is missing some support (like wasm).
Also, it is not used anywhere on the nixpkgs, while graalvm11 is used by
multiple other packages (babashka, clj-kondo, clojure-lsp, etc.).
This derivation was not updated since Jan 18, 2020. It doesn't
build on Hydra because it needs too much memory (~30GB). And no other
packages depend on it.
Also, this is a very complex package and really difficult to maintain.
It is a blocker for https://github.com/NixOS/nixpkgs/pull/141794, since
a recent bump of broke it.
`graalvm8-ce` is the replacement. It is much more up-to-date (`graalvm`
is on version 19.2.1, `graalvm8-ce` is on version 21.2.0), it is much
easier on Hydra (it uses the binary from Oracle).
I also deprecated `jvmci8` and `mx`. I am not sure if `graalvm8`
supplies them, but if something is missing we can always add it later to
`graalvm8-ce`.
the fix to extendDerivation in #140051 unwittingly worsened eval performance by
quite a bit. set elements alone needed over 1GB extra after the change, which
seems disproportionate to how small it was. if we flip the logic used to
determine which outputs to install around and keep a "this one exactly" flag in
the specific outputs instead of a "all of them" in the root we can avoid most
of that cost.
