pkl: update to 0.30.0

[subpop]

Description

Update pkl to 0.30.0

Type(s)

• bugfix
• enhancement
• security fix
• update

Tested on

macOS 26.0.1 25A362 arm64
Xcode 26.0.1 17A400

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL in commit message?
• checked your Portfile with port lint?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?
• checked that the Portfile's most important variants haven't been broken?

[reneeotten]

@subpop See comment. But also, it fails everywhere on the CI so something must be amiss.

[subpop]

@subpop See comment. But also, it fails everywhere on the CI so something must be amiss.

I saw the CI failures. I'm fairly sure it compiled locally, which is why I opened the PR, but I haven't dug through these logs yet.

[reneeotten]

Suggested change

	GRAALVM_HOME=${workpath}/graalvm
	GRAALVM_HOME=${workpath}/graalvm \

CI fails with:

  Failed to parse file lang/pkl/Portfile: invalid command name "_JAVA_OPTIONS=-Duser.home=/opt/local/var/macports/build/pkl-86203015/work/home"

[reneeotten]

@subpop with this correction the build should continue... Let's see if the CI passes, and, if so, I will merge the PR.

[reneeotten]

perhaps updating the the latest upstream version (i.e., 0.30.0) will fix the remaining issue(s).....

[subpop]

Oh that was a silly typo on my part. Thank you for catching and fixing that.

[reneeotten]

@subpop sure but it still doesn't build and couldn't have for you locally either. Please check and fix, the PR queue isn't for storing unfinished business.

[subpop]

So, it does compile locally for me:

BUILD SUCCESSFUL in 5m 33s
38 actionable tasks: 38 executed
Watched directory hierarchies: [/opt/local/var/macports/build/pkl-f42940de/work/pkl-0.29.1]
link@links-imac pkl % ls /opt/local/var/macports/build/pkl-f42940de/work/pkl-0.29.1/pkl-cli/build/executable/pkl-macos-aarch64
/opt/local/var/macports/build/pkl-f42940de/work/pkl-0.29.1/pkl-cli/build/executable/pkl-macos-aarch64
link@links-imac pkl % /opt/local/var/macports/build/pkl-f42940de/work/pkl-0.29.1/pkl-cli/build/executable/pkl-macos-aarch64 --help
Usage: pkl [<options>] <command> [<args>]...

Options:
  -v, --version  Show the version and exit
  -h, --help     Show this message and exit

Commands:
  eval              Render pkl module(s)
  repl              Start a REPL session
  server            Run as a server that communicates over standard
                    input/output
  test              Run tests within the given module(s)
  project           Run commands related to projects
  download-package  Download package(s)
  analyze           Commands related to static analysis
  shell-completion  Generate a completion script for the given shell

For more information, visit
https://pkl-lang.org/main/0.29.1/pkl-cli/index.html#usage

There must be something in the build machines that is stricter than my local setup.

[subpop]

Alright, I figured out how to get builds working locally as well as on the CI. I left the individual changes in separate commits so you can see what changed. While the CI is happy about this, I'm less happy with needing to modify the build environment like this. I'd suggest squashing all the commits into one before merging. If you'd prefer, I can squash them all and force push a new commit to this branch.

[reneeotten]

so are these changes still needed after the update to the latest upstream version? I don't use any Java based ports/packages so I am not really sure whether any of these changes make sense... Is setting HOME only affecting the build process and everything else afterward works fine? Is there a permission error or something like that when you don't set HOME? How does upstream tells you to do stuff as downstream packager?

[reneeotten]

for example. can the way Homebrew builds the package help to resolve the issue differently?

[subpop]

I completely understand. I find it bizarre that the build process is so fragile that home directory and cache directory values affect it. I did manage to get a local build succeed when I removed a few of the options. I'll push it, again in another commit, so we can see if it passes in the CI build environment.

diff --git a/lang/pkl/Portfile b/lang/pkl/Portfile
index f75a033b5b5..c4178fa4163 100644
--- a/lang/pkl/Portfile
+++ b/lang/pkl/Portfile
@@ -42,15 +42,9 @@ if {${configure.build_arch} eq "arm64"} {
 }
 build.post_args         -DreleaseBuild=true \
                         --no-daemon \
-                        -Dpkl.native-J-Duser.home=${workpath}/home
+                        -Dpkl.native-Dpolyglot.engine.userResourceCache=${workpath}/polyglot-cache
 build.env-append        GRADLE_USER_HOME=${workpath}/gradle \
-                        GRAALVM_HOME=${workpath}/graalvm \
-                        HOME=${workpath}/home \
-                        _JAVA_OPTIONS=-Duser.home=${workpath}/home
-
-pre-build {
-    xinstall -d ${workpath}/home/Library/Caches
-}
+                        GRAALVM_HOME=${workpath}/graalvm

 destroot {
     xinstall -m 0755 ${worksrcpath}/pkl-cli/build/executable/pkl-macos-${arch_name} ${destroot}${prefix}/bin/pkl