pkl: Add native build using graalvm

[ealap]

Continuing the work from #286658 and #402086 by adding support for building native pkl. On my machine, native build is on average twice as fast as the jpkl build.

I don't know much about building Java applications so I just pieced everything from patches in previous PRs.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[dtomvan]

Thank you for your first contribution, welcome to nixpkgs! I do however have some nitpicks, and then also a bug where graalvm-ce gets pulled into the derivation if nativeBuild == false.

[hugolgst]

aarch64-darwin

❌ 1 package failed to build:

• pkl

[dtomvan]

Yup, same here. here are the logs for that failure

[dtomvan]

Also, I saw someone upstream package it so that the temurin requirement is not needed anymore, should we implement that in a seperate PR?

substituteInPlace buildSrc/build.gradle.kts \ 
--replace-fail "vendor = JvmVendorSpec.ADOPTIUM" "" 
substituteInPlace buildSrc/src/main/kotlin/pklJavaLibrary.gradle.kts \
--replace-fail "vendor = info.jdkVendor" "" 
substituteInPlace buildSrc/src/main/kotlin/BuildInfo.kt \
--replace-fail "vendor.set(jdkVendor)" ""

[ealap]

Also, I saw someone upstream package it so that the temurin requirement is not needed anymore, should we implement that in a seperate PR?

substituteInPlace buildSrc/build.gradle.kts \ 
--replace-fail "vendor = JvmVendorSpec.ADOPTIUM" "" 
substituteInPlace buildSrc/src/main/kotlin/pklJavaLibrary.gradle.kts \
--replace-fail "vendor = info.jdkVendor" "" 
substituteInPlace buildSrc/src/main/kotlin/BuildInfo.kt \
--replace-fail "vendor.set(jdkVendor)" ""

I can confirm that this works! Could I include here on a separate commit or is it much preferred here to create separate PR?

[hugolgst]

I think it could be fine in this PR

[ealap]

I'm unable to build this now :(

[1/8] Initializing...                                                                                    (0.0s @ 0.15GB)
Error: Polyglot version compatibility check failed.
Your Java runtime '24.0.1+9-jvmci-b01' with native-image feature version '24.2.1' is incompatible with polyglot version '24.1.2'.
Update the org.graalvm.polyglot versions to at least '24.2.1' to resolve this.

I'm not quite sure but does this mean nixpkgs' graalvm-ce version is not compatible with pkl's lockfiles anymore? I see an update from 23 to 24 was recently merged.

cc: @bioball

[dtomvan]

I see an update from 23 to 24 was recently merged.

graalvm-ce doesn't seem to have versioned packages. I know it's unfree, but I got it building and working again by replacing graalvmPackages.graalvm-ce with graalvmPackages.graalvm-oracle_23. I don't know what would be best here, since in that PR most packages which depend on graalvm-ce seem to continue working, so keeping old ce-versions around as is done with the JDK might not be worth it.

There might also be value in using whatever GraalVM we use for the native step as the JDK we use for gradle/kotlinc, so jdk.version == graalvmDir.version? Because currently, we depend on a JDK 24 for GraalVM, but JDK 21 for Gradle.

[dtomvan]

One problem I found is that the current version of KGP they use in libs.versions.toml, 2.0.21, does not know what JDK 23 is. So using GraalVM 23 as JDK target doesn't seem possible as of now.

FWIW I can get it building with the following patch:

default-openjdk-graalvm-23.patch

diff --git i/pkgs/by-name/pk/pkl/package.nix w/pkgs/by-name/pk/pkl/package.nix
index da54a38d7fad..12d08ba2d469 100644
--- i/pkgs/by-name/pk/pkl/package.nix
+++ w/pkgs/by-name/pk/pkl/package.nix
@@ -3,18 +3,21 @@
   lib,
   fetchFromGitHub,
   gradle,
-  temurin-bin-21,
   kotlin,
   nix-update-script,
   replaceVars,
   makeWrapper,
   graalvmPackages,
+  openjdk,
   buildNative ? true,
 }:
 let
-  jdk = temurin-bin-21;
+  jdk = openjdk;
+  jdkMajorVersion = lib.versions.major jdk.version;
+  graalvmDir = graalvmPackages.graalvm-oracle_23;
   gradleOverlay = gradle.override { java = jdk; };
   kotlinOverlay = kotlin.override { jre = jdk; };
+
   binaries = {
     aarch64-darwin = "pkl-macos-aarch64";
     aarch64-linux = "pkl-linux-aarch64";
@@ -54,14 +57,24 @@ stdenv.mkDerivation (finalAttrs: {
     ++ (
       if nativeBuild then
         [
-          (replaceVars ./use_nix_graalvm_instead_of_download.patch {
-            graalvmDir = graalvmPackages.graalvm-ce;
-          })
+          (replaceVars ./use_nix_graalvm_instead_of_download.patch { inherit graalvmDir; })
         ]
       else
         [ ]
     );
 
+  postPatch = ''
+    substituteInPlace buildSrc/build.gradle.kts \
+      --replace-fail "vendor = JvmVendorSpec.ADOPTIUM" "" \
+      --replace-fail "toolchainVersion = 21" "toolchainVersion = ${jdkMajorVersion}"
+
+    substituteInPlace buildSrc/src/main/kotlin/pklJavaLibrary.gradle.kts \
+      --replace-fail "vendor = info.jdkVendor" ""
+
+    substituteInPlace buildSrc/src/main/kotlin/BuildInfo.kt \
+      --replace-fail "vendor.set(jdkVendor)" ""
+  '';
+
   nativeBuildInputs = [
     gradleOverlay
     jdk

[dtomvan]

Any blocker for this PR? Shall I attract some committer to here via discourse?

[ealap]

We still have these build failure on darwin
https://github.com/ealap/nixpkgs-review-gha/actions/runs/15281953003/job/42982915260

which I don't understand, unfortunately.

[bioball]

Looks like the error is happening when Truffle is trying to copy a native library onto the host machine.

Try adding these CLI flags when calling into ./gradlew:

-Dpkl.native-Dpolyglotimpl.AttachLibraryFailureAction=ignore -Dpkl.native-Dtruffle.UseFallbackRuntime=true

Might also be good to add -Dpkl.native-H:-CopyLanguageResources.

[ealap]

Looks like the error is happening when Truffle is trying to copy a native library onto the host machine.

Try adding these CLI flags when calling into ./gradlew:

-Dpkl.native-Dpolyglotimpl.AttachLibraryFailureAction=ignore -Dpkl.native-Dtruffle.UseFallbackRuntime=true

Might also be good to add -Dpkl.native-H:-CopyLanguageResources.

Thanks @bioball! Unfortunately, it still fails on the same error message. I wonder it only happens on macos.

[bioball]

It has to do with filesystem permissions; the build is trying to copy files into /var/empty/Library:

pkl> Caused by: java.nio.file.AccessDeniedException: /var/empty/Library
pkl>    at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90)
pkl>    at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
pkl>    at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
pkl>    at java.base/sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:463)
pkl>    at java.base/java.nio.file.Files.createDirectory(Files.java:700)
pkl>    at java.base/java.nio.file.Files.createAndCheckIsDirectory(Files.java:808)
pkl>    at java.base/java.nio.file.Files.createDirectories(Files.java:794)
pkl>    at org.graalvm.truffle/com.oracle.truffle.polyglot.InternalResourceCache.installResource(InternalResourceCache.java:233)
pkl>    at org.graalvm.truffle/com.oracle.truffle.polyglot.InternalResourceCache.installRuntimeResource(InternalResourceCache.java:190)
pkl>    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
pkl>    ... 23 more

Looking at this PR, I'm not sure where /var/empty is being set, but alternatively, you can also try giving it a directory that's writable.