This bumps Clikt from version 3 to version 5, which, among other things, improves
the help text formatting with colors.
Also:
* Add `--version` flag to pkldoc, pkl-codegen-java, pkl-codegen-kotlin
* Add help text to pkldoc, pkl-codegen-java, pkl-codegen-kotlin
This updates the GraalVM and Truffle libraries to 2024.1.2.
This also updates the build logic to compile Java sources using Java 21, due to some compile-only dependencies within GraalVM/Truffle using class file version 65. However, the produced artifact is still compatible with Java 17.
This also changes the Gradle build logic to use toolchains, and to test the Java libraries with JDK 17 and 21.
One consequence of this change is that Truffle is no longer shaded within the fat jars.
feat: support for jvm21+ toolchain
feat: support for gradle toolchains
feat: pass -PnativeArch=native to build with -march=native
test: multi-jdk testing support
test: support for jvm-test-suite plugin
test: add tasks to run jpkl eval on multiple jdks
test: make jdk exec tests respect multi-jdk flags and ranges
fix: remove mrjar classes at >jvm17 from fatjars
fix: use jdk21 to run the tests (needed for Unsafe.ensureInitialized)
fix: truffle svm dependency is required after graalvm 24.0.0
fix: warnings for gvm flag usage, renamed truffle svm macro
fix: build with --add-modules=jdk.unsupported where needed
fix: don't use gu tool for modern graalvm versions
fix: catch Throwable instead of deprecated-for-removal ThreadDeath
chore: buildinfo changes for JVM targets, toolchains
chore: enforce testing at exactly jdk21
chore: enforce build tooling at jdk21+
chore: bump graalvm/truffle libs → 24.1.2
chore: toolchains for buildSrc
Signed-off-by: Sam Gammon <sam@elide.dev>
SVM (SubstrateVM) compile configuration classes
must be included within the `cli` jar to prevent
downstream `native-image` builds from failing.
Fat JARs cannot be used with `native-image`, so
these classes can still safely be excluded here.
Fixes and closesapple/pkl#907
Signed-off-by: Sam Gammon <sam@elide.dev>
Graal Native Image is assuming 4k page size here, which is a naughty assumption to make in the modern Linux-on-ARM landscape.
Two very common hardware configurations require 16k minumum page size: the Raspberry Pi 5 and Asahi Linux (running on Apple Silicon hardware).
This change forces 64k pages for Linux/AArch64 native executables to guarantee compatibility with these platforms.
DEVELOPMENT.adoc is also updated to cover the additional dependencies required for building native executables on Linux.
To make error messages from Pkl eval easier to read, this change uses
the Jansi library to colour the output, making it quicker and easier to
scan error messages and understand what's happened.
The Jansi library also detects if the CLI output is a terminal capable
of handling colours, and will automatically strip out escape codes if
the output won't support them (e.g. piping the output somewhere else).
This addresses an issue where network requests may fail if cert revocation checks
error, which may occur due to availability issues, or due to lack of internet access.
Revocation checking can still be enabled by setting JVM property com.sun.net.ssl.checkRevocation if on the JVM.
Also:
* Load built-in certs from resources, and move them to pkl-commons-cli
* Fix an issue where HttpInitException is not caught when loading a module
Instead of bundling Pkl's built-in CA certificates as a class path resource and loading them at runtime,
pass them to the native image compiler as the default SSL context's trust store.
This results in faster SSL initialization and is more consistent with how default certificates
are handled when running on the JVM.
Further related improvements:
- Remove HttpClientBuilder methods `addDefaultCliCertificates` and `addBuiltInCertificates`.
- Remove pkl-certs subproject and the optional dependencies on it.
- Move `PklCARoots.pem` to `pkl-cli/src/certs`.
- Fix certificate related error messages that were missing an argument.
- Prevent PklBugException if initialization of `CliBaseOptions.httpClient` fails.
- Add ability to set CA certificates as a byte array
- Add CA certificates option to message passing API
* Add `--proxy` and `--no-proxy` CLI flags
* Add property `http` to `pkl:settings`
* Move `EvaluatorSettings` from `pkl:Project` to its own module and add property `http`
* Add support for proxying in server mode, and through Gradle
* Add `setProxy()` to `HttpClient`
* Add documentation
* Don't expose JDK internal classes; instead solve msgpack issue with `--initialize-at-run-time`.
* Use quick build mode for non-release builds: 40% faster compilation, 20% smaller executable.
* Remove options that were commented out.
* Also run ServerTest against native executable
This adds support for Windows.
The in-language path separator is still `/`, to ensure Pkl programs are cross-platform.
Log lines are written using CRLF endings on Windows.
Modules that are combined with `--module-output-separator` uses LF endings to ensure
consistent rendering across platforms.
`jpkl` does not work on Windows as a direct executable.
However, it can work with `java -jar jpkl`.
Additional details:
* Adjust git settings for Windows
* Add native executable for pkl cli
* Add jdk17 windows Gradle check in CI
* Adjust CI test reports to be staged within Gradle rather than by shell script.
* Fix: encode more characters that are not safe Windows paths
* Skip running tests involving symbolic links on Windows (these require administrator privileges to run).
* Introduce custom implementation of `IoUtils.relativize`
* Allow Gradle to initialize ExecutableJar `Property` values
* Add Gradle flag to enable remote JVM debugging
Co-authored-by: Philip K.F. Hölzenspies <holzensp@gmail.com>
* Remove unnecessary strictfp modifier
* Add annotations to address Truffle DSL warnings (@Idempotent, @Exclusive)
* Adjust build logic to allow building cross-arch on macOS
* Add warning suppression for specialization limit (left this one as a TODO)
- Fix and clean up the pkl-commons-test build script.
- Change tests to read test packages/certs directly from
the file system instead of packaging and reading them
from the class path.
- Update expected checksums of some test packages.
- Fix a conflict between Pkl's and Gradle's
Kotlin libraries in the pkl-gradle project.
- Fix build deprecation warnings.
- Ensure Gradle distribution integrity with `distributionSha256Sum`.
- Manually verify integrity of Gradle wrapper added by this commit.
Moving to java.net.http.HttpClient brings many benefits, including
HTTP/2 support and the ability to make asynchronous requests.
Major additions and changes:
- Introduce a lightweight org.pkl.core.http.HttpClient API.
This keeps some flexibility and allows to enforce behavior
such as setting the User-Agent header.
- Provide an implementation that delegates to java.net.http.HttpClient.
- Use HttpClient for all HTTP(s) requests across the codebase.
This required adding an HttpClient parameter to constructors and
factory methods of multiple classes, some of which are public APIs.
- Manage CA certificates per HTTP client instead of per JVM.
This makes it unnecessary to set JVM-wide system/security properties
and default SSLSocketFactory's.
- Add executor v2 options to the executor SPI
- Add pkl-certs as a new artifact, and remove certs from pkl-commons-cli artifact
Each HTTP client maintains its own connection pool and SSLContext.
For efficiency reasons, It's best to reuse clients whenever feasible.
To avoid memory leaks, clients are not stored in static fields.
HTTP clients are expensive to create. For this reason,
EvaluatorBuilder defaults to a "lazy" client that creates the underlying
java.net.http.HttpClient on the first send (which may never happen).
This change activates the `TYPESAFE_PROJECT_ACCESSORS` feature
preview in Gradle, and switches to such accessors instead of
string-based project references, where possible
Relates-To: apple/pkl#204
Signed-off-by: Sam Gammon <sam@elide.ventures>
This improves the development experience for (WSL) Linux users.
They can now run "./gradlew buildNative" without having a musl toolchain installed.
In this case, only the dynamically linked executable will be built.
