In #168816, we removed support for Python/Ruby/WASM to reduce the
support burden of GraalVM languages that, arguably, are not really being
used.
However, the way that `pkgs.graalvmCEPackages.mkGraal` function works
right now doesn't allow passing a custom sources file, that would allow
someone to compile GraalVM with the additional products (e.g.: Python).
This PR adds this possibility.
So if someone wants to create a custom graalvm11-ce derivation with
Python support, for example, they can do something like this:
```nix
let
graalvm11-ce-custom = pkgs.graalvmCEPackages.mkGraal {
config = {
x86_64-linux = {
products = [ "graalvm-ce" "python-installable-svm" ];
arch = "linux-amd64";
};
};
defaultVersion = "22.0.0.2";
javaVersion = "11";
platforms = "x86_64-linux";
sourcesPath = /home/someone/graalvm11-ce-sources.json;
};
in
{
environment.systemPackages = [ graalvm11-ce-custom ];
}
```
Those additional languages does not seem to really have much usage
(e.g.: none in nixpkgs). For example, Ruby is pretty much broken for all
environments for quite sometime already, however nobody seemed to border
enough to fix it. They also add a good amount of size to the derivation.
So let's remove them. It should be really easy if someone still cares
for them and want to add them back on their own system: just use the
`mkGraal` function (that we export) to generate their own version of
GraalVM with all extra features they want.
This package was last updated in 2020. It is out-of-date compared to
upstream and we have the graalvmXX-ce already, that is much better
maintained nowadays.
Test suite assumes access to the `hostname` command, and a few
other gnu coreutil assumptions, not compatible with darwin.
Enable doInstallCheck to compensate
This commit adds entries to the Rosetta Stones in
adoptopenjdk-bin/generate-sources.py and compilers/openjdk/8.nix, and
runs adoptopenjdk-bin/generate-sources.py to regenerate
adoptopenjdk-bin/sources.json.
With this commit, `nix-build . -A jdk8_headless` succeeds on
powerpc64le. Headless jdk is used as part of the build process for
many packages so this opens up access to them.
Current bsc releases ship a tarball of the expected version of the yices
source, so switch to using that rather than gamble on the nixpkgs yices
version.
Signed-off-by: David Anderson <dave@natulte.net>
There are many different versions of the `cudatoolkit` and related
cuda packages, and it can be tricky to ensure they remain compatible.
- `cudaPackages` is now a package set with `cudatoolkit`, `cudnn`, `cutensor`, `nccl`, as well as `cudatoolkit` split into smaller packages ("redist");
- expressions should now use `cudaPackages` as parameter instead of the individual cuda packages;
- `makeScope` is now used, so it is possible to use `.overrideScope'` to set e.g. a different `cudnn` version;
- `release-cuda.nix` is introduced to easily evaluate cuda packages using hydra.
