Release: `0.10.x` #80

sgammon · 2023-09-01T07:50:42Z

Summary

This branch prepares a suite of changes for collective release under the 0.10.x series. This includes several (small) backward-incompatible changes, which are documented below.

PR Tree

Dependency updates

Related issues

Breaking changes

The default_executable_name attribute and parameter has been renamed to executable_name.
This is because there is no other executable name parameter; setting this attribute will unconditionally change the output binary name.
Legacy GVM is only usable with the legacy rules.
Previously, it was possible to use a rather old version of GraalVM (Java 11-era) with the new-style rules. This use is no longer supported because older versions of native-image show incompatibilities with Bazel's process wrapper.
Native image builds will now respect Bazel flags like --compilation_mode=opt.
Defaults have been left to GraalVM to maintain backward compatibility with the default case, which builds binaries with -O2 (optimizations on). However, this is still a breaking change because the behavior will be different if --compilation_mode was being explicitly set to any value other than opt. Note that Bazel's default value of fastbuild also applies here, so passing no value at all will result in a behavior change (opt → fastbuild).
The order of options passed to native-image has changed.
Attributes like extra_args now pass later on the command line (last, actually, for extra_args); because native-image options are last-wins, this should allow overriding any of the flags injected by the rules. This should offer users a path forward even if the flags passed by the rules are incompatible in some way. This change in the order of action arguments may result in cache misses. Otherwise, this change should be transparent to rule users.
Hermetic build environment improvements.
The parameter use_default_shell_env is no longer passed to the underlying native-image compile action; instead, the toolchain environment is assembled for strict use. Native compiler environment variables like INCLUDE, LIB, DEVELOPER_DIR, and SDKROOT no longer need to be passed via --action_env.
Toolchain targets and registration.
See below for an exhaustive description, but basically, the registration calls for toolchains need to change, but only for users who are consuming via Bzlmod.

Breaking changes: Toolchain registration

When registering toolchains in a Bzlmod installation of these rules, the target @graalvm//:all must be changed to two toolchain registrations, based on the desired functionality:

Register the Java toolchain:

register_toolchains("@graalvm//:jvm")

Register the GVM toolchain:

register_toolchains("@graalvm//:sdk")

internal/native_image/builder.bzl

internal/native_image/classic.bzl

internal/native_image/common.bzl

internal/native_image/rules.bzl

fmeum · 2023-09-01T15:20:33Z

@sgammon Does this include the toolchain repo separation?

sgammon · 2023-09-01T18:53:39Z

@fmeum nice work, it looks like all checks are passing locally. This doesn't include the toolchain repo separation yet but it can, that change should be quick and I'd love to get it in under this release.

sgammon

Lazy toolchains

@fmeum With this change, the GVM toolchain now adopts the same structure as the Java toolchain. i couldn't figure out how to make this change without a small backward-incompatible update to the toolchain registration process, but it should be okay since we're releasing at 0.10.x, and I'll document the change in release notes.

Before 0.10.x:

flowchart TD
    A(graalvm) -->|Alias| B(graalvm_toolchain_config_repo)
    B-->C[Java toolchain]
    A-->|toolchain target|D[GVM toolchain]

After 0.10.x:

flowchart TD
    A(graalvm) -->|"Alias //:jvm"| C(graalvm_toolchain_config_repo)
    A-->|graalvm_sdk| B["//:gvm"]
    C-->|Java toolchain| D["//:toolchain"]
    A-->|"Alias //:sdk"|C
    C-->|"GVM toolchain"| E["//:gvm"]
    D-->|"SDK target"|B

This feels overly complex, but it felt wrong to define the graalvm_sdk target in the toolchain_config_repo, since those resources are actually in that repository. No matter what, I'd have to either (a) reference back to the files in a circular manner, or (b) move the GraalVM SDK call to the toolchain config repo (and reference files anyway), or (c) add a third repo, none of which seemed optimal. If you have any ideas here they are welcome.

Ideally, the actual file targets inside the GraalVM SDK could be kept private, to prevent users from binding to the internal implementation structure of the SDK, but maybe that's unavoidable or not our job to enforce.

I'm open to feedback on this and I'm curious if this solves the lazy download issue you surfaced in #66.

Inert integration tests

I've added the inert and inert-workspace tests which install @graalvm, but do not register toolchains or have native_image targets. As far as I can tell, these tests run fine and don't download GraalVM.

If you are looking to model behavior that isn't represented in these tests, please feel free to adjust them so they reflect reality.

.github/workflows/module.build.yml

README.md

example/integration_tests/bazel5/WORKSPACE.bazel

example/integration_tests/inert-workspace/WORKSPACE.bazel

example/integration_tests/inert/MODULE.bazel

example/integration_tests/java-toolchain/sample/Main.java

- test: add `java-toolchain` test, which exercises graalvm as the bazel tool/runtime java toolchain. - test: add `components-ce` test, which downloads GVM Community components with dependencies. - test: add `components-gvm` test, which downloads Oracle GVM components with `gu`. - test: add `disabled_tests` with tests for earlier versions of bazel (coming soon), including `bazel1`, `bazel2`, and `bazel3` - test: move most tests to GVM Community (except where noted) Signed-off-by: Sam Gammon <sam@elide.ventures>