Release: 0.10.x

[sgammon]

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

• feat: graalvm artifact mappings #106
• fix: install requested components plus deps #101
• fix: typo in gu post-install actions #99
• feat: bazel settings integration #86
• test: add more feature integration tests #84
• fix(toolchain): add alias indirection for gvm toolchain #82
• fix(native_image): fix C++ toolchain env setup #72
• feat(native_image): add static_zlib #73
• fix: bcr tarball endpoint #76
• fix(native_image): clean up args building #71
• fix(native_image): clean up construction of inputs #70
• Use ; as classpath separator on Windows #68
• docs: fix api docs and publish flow #63

Dependency updates

• chore(deps): bump actions/upload-artifact from 3.1.2 to 3.1.3 #112
• chore(deps): bump actions/checkout from 3.6.0 to 4.0.0 #111
• chore(deps-dev): bump prettier-plugin-java from 2.3.0 to 2.3.1 #110
• chore(deps): lock file maintenance #104
• chore(deps): update googleapis digest to 2a10735 #93
• chore(deps): update dependency aspect_bazel_lib to v1.34.1 #94
• chore(deps): update dependency bazel to v7.0.0-pre.20230823.4 #95
• chore(deps): update dependency buildifier_prebuilt to v6.3.3 #96
• chore(deps): update dependency io_bazel_stardoc to v0.6.2 #97
• chore(deps): update dependency bazel_features to v1 #98

Related issues

• Typo in the gu post-install actions #102
• Component direct dependencies not installed #100
• Ability to build a shared library #85
• Bazel Settings Propagation #78
• Populate environment for macOS builds #67
• Download GraalVM distributions lazily #66

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")

[fmeum]

@sgammon Does this include the toolchain repo separation?

[sgammon]

@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]

Loading

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

Loading

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.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information