2023-02-08 21:26:19 +00:00
|
|
|
{ lib
|
|
|
|
, stdenv
|
|
|
|
, alsa-lib
|
|
|
|
, autoPatchelfHook
|
|
|
|
, cairo
|
|
|
|
, cups
|
2023-02-14 19:04:12 +00:00
|
|
|
, darwin
|
2023-02-08 21:26:19 +00:00
|
|
|
, fontconfig
|
|
|
|
, glib
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
, glibc
|
2023-02-08 21:26:19 +00:00
|
|
|
, gtk3
|
|
|
|
, makeWrapper
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
, musl
|
2023-09-27 21:09:41 +01:00
|
|
|
, runCommandCC
|
2023-02-08 21:56:10 +00:00
|
|
|
, setJavaClassPath
|
2023-02-08 21:26:19 +00:00
|
|
|
, unzip
|
|
|
|
, xorg
|
|
|
|
, zlib
|
2023-02-14 19:04:12 +00:00
|
|
|
# extra params
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
, extraCLibs ? [ ]
|
2023-02-14 19:04:12 +00:00
|
|
|
, gtkSupport ? stdenv.isLinux
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
, useMusl ? false
|
2023-02-14 17:00:45 +00:00
|
|
|
, ...
|
|
|
|
} @ args:
|
2023-02-08 21:26:19 +00:00
|
|
|
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
assert useMusl -> stdenv.isLinux;
|
2023-02-08 21:26:19 +00:00
|
|
|
let
|
2023-02-14 19:04:12 +00:00
|
|
|
extraArgs = builtins.removeAttrs args [
|
2023-09-27 10:25:09 +01:00
|
|
|
"lib"
|
|
|
|
"stdenv"
|
2023-02-14 19:04:12 +00:00
|
|
|
"alsa-lib"
|
|
|
|
"autoPatchelfHook"
|
|
|
|
"cairo"
|
|
|
|
"cups"
|
|
|
|
"darwin"
|
|
|
|
"fontconfig"
|
|
|
|
"glib"
|
2023-09-27 10:25:09 +01:00
|
|
|
"glibc"
|
2023-02-14 19:04:12 +00:00
|
|
|
"gtk3"
|
|
|
|
"makeWrapper"
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
"musl"
|
2023-09-27 21:09:41 +01:00
|
|
|
"runCommandCC"
|
2023-02-14 19:04:12 +00:00
|
|
|
"setJavaClassPath"
|
|
|
|
"unzip"
|
|
|
|
"xorg"
|
|
|
|
"zlib"
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
"extraCLibs"
|
2023-02-14 19:04:12 +00:00
|
|
|
"gtkSupport"
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
"useMusl"
|
|
|
|
"passthru"
|
|
|
|
"meta"
|
2023-02-14 19:04:12 +00:00
|
|
|
];
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
|
2023-09-27 21:09:41 +01:00
|
|
|
cLibs = lib.optionals stdenv.isLinux (
|
|
|
|
[ glibc zlib.static ]
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
++ lib.optionals (!useMusl) [ glibc.static ]
|
|
|
|
++ lib.optionals useMusl [ musl ]
|
2023-09-27 21:09:41 +01:00
|
|
|
++ extraCLibs
|
|
|
|
);
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
|
|
|
|
# GraalVM 21.3.0+ expects musl-gcc as <system>-musl-gcc
|
2023-09-27 22:50:34 +01:00
|
|
|
musl-gcc = (runCommandCC "musl-gcc" { } ''
|
|
|
|
mkdir -p $out/bin
|
|
|
|
ln -s ${lib.getDev musl}/bin/musl-gcc $out/bin/${stdenv.hostPlatform.system}-musl-gcc
|
|
|
|
'');
|
2023-12-13 11:52:44 +00:00
|
|
|
binPath = lib.makeBinPath (lib.optionals useMusl [ musl-gcc ] ++ [ stdenv.cc ]);
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
|
2023-02-08 21:26:19 +00:00
|
|
|
runtimeLibraryPath = lib.makeLibraryPath
|
|
|
|
([ cups ] ++ lib.optionals gtkSupport [ cairo glib gtk3 ]);
|
2023-02-09 22:13:18 +00:00
|
|
|
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
graalvm-ce = stdenv.mkDerivation ({
|
|
|
|
pname = "graalvm-ce";
|
2023-02-09 22:13:18 +00:00
|
|
|
|
|
|
|
unpackPhase = ''
|
|
|
|
runHook preUnpack
|
|
|
|
|
|
|
|
mkdir -p "$out"
|
|
|
|
|
|
|
|
# The tarball on Linux has the following directory structure:
|
|
|
|
#
|
|
|
|
# graalvm-ce-java11-20.3.0/*
|
|
|
|
#
|
|
|
|
# while on Darwin it looks like this:
|
|
|
|
#
|
|
|
|
# graalvm-ce-java11-20.3.0/Contents/Home/*
|
|
|
|
#
|
|
|
|
# We therefor use --strip-components=1 vs 3 depending on the platform.
|
|
|
|
tar xf "$src" -C "$out" --strip-components=${
|
|
|
|
if stdenv.isLinux then "1" else "3"
|
|
|
|
}
|
|
|
|
|
|
|
|
# Sanity check
|
|
|
|
if [ ! -d "$out/bin" ]; then
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
echo "The `bin` is directory missing after extracting the graalvm"
|
|
|
|
echo "tarball, please compare the directory structure of the"
|
|
|
|
echo "tarball with what happens in the unpackPhase (in particular"
|
|
|
|
echo "with regards to the `--strip-components` flag)."
|
|
|
|
exit 1
|
2023-02-09 22:13:18 +00:00
|
|
|
fi
|
|
|
|
|
|
|
|
runHook postUnpack
|
|
|
|
'';
|
|
|
|
|
|
|
|
dontStrip = true;
|
|
|
|
|
|
|
|
nativeBuildInputs = [ unzip makeWrapper ]
|
2023-02-09 23:41:40 +00:00
|
|
|
++ lib.optional stdenv.isLinux autoPatchelfHook;
|
2023-02-09 22:13:18 +00:00
|
|
|
|
2023-02-09 23:18:10 +00:00
|
|
|
propagatedBuildInputs = [ setJavaClassPath zlib ]
|
2023-02-14 19:04:12 +00:00
|
|
|
++ lib.optional stdenv.isDarwin darwin.apple_sdk.frameworks.Foundation;
|
2023-02-09 22:13:18 +00:00
|
|
|
|
2023-02-09 23:18:10 +00:00
|
|
|
buildInputs = lib.optionals stdenv.isLinux [
|
2023-02-09 22:13:18 +00:00
|
|
|
alsa-lib # libasound.so wanted by lib/libjsound.so
|
|
|
|
fontconfig
|
|
|
|
stdenv.cc.cc.lib # libstdc++.so.6
|
|
|
|
xorg.libX11
|
|
|
|
xorg.libXext
|
|
|
|
xorg.libXi
|
|
|
|
xorg.libXrender
|
|
|
|
xorg.libXtst
|
2023-02-09 23:41:40 +00:00
|
|
|
];
|
2023-02-09 22:13:18 +00:00
|
|
|
|
|
|
|
postInstall = ''
|
|
|
|
# jni.h expects jni_md.h to be in the header search path.
|
|
|
|
ln -sf $out/include/linux/*_md.h $out/include/
|
|
|
|
|
|
|
|
# copy-paste openjdk's preFixup
|
|
|
|
# Set JAVA_HOME automatically.
|
|
|
|
mkdir -p $out/nix-support
|
|
|
|
cat > $out/nix-support/setup-hook << EOF
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
if [ -z "\''${JAVA_HOME-}" ]; then export JAVA_HOME=$out; fi
|
2023-02-09 22:13:18 +00:00
|
|
|
EOF
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
|
2023-09-27 21:09:41 +01:00
|
|
|
wrapProgram $out/bin/native-image \
|
|
|
|
--prefix PATH : ${binPath} \
|
|
|
|
${toString (map (l: "--add-flags '-H:CLibraryPath=${l}/lib'") cLibs)}
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
'';
|
2023-02-09 22:13:18 +00:00
|
|
|
|
|
|
|
preFixup = lib.optionalString (stdenv.isLinux) ''
|
2023-02-15 21:53:52 +00:00
|
|
|
for bin in $(find "$out/bin" -executable -type f); do
|
2023-02-09 22:13:18 +00:00
|
|
|
wrapProgram "$bin" --prefix LD_LIBRARY_PATH : "${runtimeLibraryPath}"
|
|
|
|
done
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
'';
|
2023-02-09 22:13:18 +00:00
|
|
|
|
|
|
|
doInstallCheck = true;
|
|
|
|
installCheckPhase = ''
|
|
|
|
runHook preInstallCheck
|
|
|
|
|
2023-02-14 17:00:01 +00:00
|
|
|
${# broken in darwin
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
lib.optionalString stdenv.isLinux ''
|
2023-02-14 17:00:01 +00:00
|
|
|
echo "Testing Jshell"
|
|
|
|
echo '1 + 1' | $out/bin/jshell
|
|
|
|
''}
|
2023-02-13 21:19:42 +00:00
|
|
|
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
echo ${lib.escapeShellArg ''
|
|
|
|
public class HelloWorld {
|
|
|
|
public static void main(String[] args) {
|
|
|
|
System.out.println("Hello World");
|
2023-02-08 21:26:19 +00:00
|
|
|
}
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
}
|
|
|
|
''} > HelloWorld.java
|
2023-02-09 22:13:18 +00:00
|
|
|
$out/bin/javac HelloWorld.java
|
|
|
|
|
|
|
|
# run on JVM with Graal Compiler
|
|
|
|
echo "Testing GraalVM"
|
|
|
|
$out/bin/java -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler HelloWorld | fgrep 'Hello World'
|
|
|
|
|
2024-03-26 14:11:31 +00:00
|
|
|
extraNativeImageArgs="$(export -p | sed -n 's/^declare -x \([^=]\+\)=.*$/ -E\1/p' | tr -d \\n)"
|
2023-12-13 11:52:44 +00:00
|
|
|
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
echo "Ahead-Of-Time compilation"
|
2024-03-26 14:11:31 +00:00
|
|
|
$out/bin/native-image -H:+UnlockExperimentalVMOptions -H:-CheckToolchain -H:+ReportExceptionStackTraces -march=compatibility $extraNativeImageArgs HelloWorld
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
./helloworld | fgrep 'Hello World'
|
|
|
|
|
|
|
|
${# --static is only available in Linux
|
|
|
|
lib.optionalString (stdenv.isLinux && !useMusl) ''
|
|
|
|
echo "Ahead-Of-Time compilation with -H:+StaticExecutableWithDynamicLibC"
|
2024-03-26 14:11:31 +00:00
|
|
|
$out/bin/native-image -H:+UnlockExperimentalVMOptions -H:+StaticExecutableWithDynamicLibC -march=compatibility $extraNativeImageArgs HelloWorld
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
./helloworld | fgrep 'Hello World'
|
|
|
|
|
|
|
|
echo "Ahead-Of-Time compilation with --static"
|
2024-03-26 14:11:31 +00:00
|
|
|
$out/bin/native-image $extraNativeImageArgs -march=compatibility --static HelloWorld
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
./helloworld | fgrep 'Hello World'
|
|
|
|
''}
|
|
|
|
|
|
|
|
${# --static is only available in Linux
|
|
|
|
lib.optionalString (stdenv.isLinux && useMusl) ''
|
|
|
|
echo "Ahead-Of-Time compilation with --static and --libc=musl"
|
2024-03-26 14:11:31 +00:00
|
|
|
$out/bin/native-image $extraNativeImageArgs -march=compatibility --libc=musl --static HelloWorld
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
./helloworld | fgrep 'Hello World'
|
|
|
|
''}
|
2023-02-09 22:13:18 +00:00
|
|
|
|
|
|
|
runHook postInstallCheck
|
|
|
|
'';
|
|
|
|
|
|
|
|
passthru = {
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
home = graalvm-ce;
|
2023-09-26 19:15:43 +01:00
|
|
|
updateScript = [ ./update.sh "graalvm-ce" ];
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
} // (args.passhtru or { });
|
2023-02-09 22:13:18 +00:00
|
|
|
|
|
|
|
meta = with lib; ({
|
|
|
|
homepage = "https://www.graalvm.org/";
|
|
|
|
description = "High-Performance Polyglot VM";
|
|
|
|
license = with licenses; [ upl gpl2Classpath bsd3 ];
|
|
|
|
sourceProvenance = with sourceTypes; [ binaryNativeCode ];
|
|
|
|
mainProgram = "java";
|
2023-02-09 23:46:19 +00:00
|
|
|
maintainers = with maintainers; teams.graalvm-ce.members ++ [ ];
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
} // (args.meta or { }));
|
2023-02-14 19:04:12 +00:00
|
|
|
} // extraArgs);
|
2023-02-14 17:00:45 +00:00
|
|
|
in
|
graalvm-ce: 22.3.1 -> 21.0.0
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
2023-09-26 13:03:23 +01:00
|
|
|
graalvm-ce
|