Skip to content

Copy GraalVM under shorter path on Windows CI #4917

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

alexarchambault
Copy link
Collaborator

This adds a nativeImageMaybeCopyGraal command on NativeImageModule. This command only has an effect if NativeImageModule#nativeImageGraalVmCopyBase: Option[os.Path] is non-empty. By default, it's non-empty only in Windows CI environments, where it's Some(os.Path("C:/jvms")). nativeImageMaybeCopyGraal copies the GraalVM distribution under a sub-directory of it, like C:\jvms\5aa5d09c. 5aa5d09c is a hash of the original GraalVM distribution path.

If this directory exists, NativeImageModule#nativeImageTool uses it rather than the original GraalVM distribution, to get the path of native-image. This offers a workaround for too long paths of GraalVM header files, that we run into sometimes on the CI (more on fork CIs than in the main repo, in my experience).

This allows to get rid of the coursier archive cache customizations on the CI, that were meant to work around that problem too. The resulting paths were sometimes still too long, given they contain the URL of the GraalVM distribution, like C:\coursier-arc\https\github.com\graalvm\graalvm-ce-builds\releases\download\jdk-23.0.1\graalvm-community-jdk-23.0.1_windows-x64_bin.zip\. In constrast, with this PR, we get GraalVM distribution paths like C:\jvms\5aa5d09c.

They might disappear across runs, given they're externally managed
These are run like the '/** Usage' ones, but are not put on the website
@alexarchambault
Copy link
Collaborator Author

This also copies the changes in NativeImageModule in dist/package.mill, so that we can benefit from them right away. Applying ci/mill-bootstrap.patch when re-bootstrapping should remove those.

@alexarchambault
Copy link
Collaborator Author

About #4907 (comment), this could be added in coursier. Maybe with something like

ArchiveCache().withShortPathDir(Some(new File("C:/jvms")))

That way, we'd only have to keep NativeImageModule#nativeImageGraalVmCopyBase here (maybe moved to JvmWorkerModule)

@lihaoyi
Copy link
Member

lihaoyi commented Apr 11, 2025

Looking at this PR it feels like it's exposing too much complexity in the API: asking the user to configure an explicit path, and then asking the user to call a separate command to copy things to that explicit path, both seem like incidental complexity that we should try and avoid.

Are there any other options? e.g. Can we always copy the Graal binary to a shorter path in ~/.cache/mill/graal/<hash> before running it?

@alexarchambault
Copy link
Collaborator Author

i reverted all changes, and made it use coursier/coursier#3373 (this needs coursier 2.1.25-M5, whose release is on-going). Going to try to enable it in the bootstrap job via ci/mill-bootstrap.patch (and we should benefit from it here after re-bootstrapping).

Comment on lines 625 to 626
if (isWin) os.Path(System.getenv("UserProfile")) / ".mill/cache/jvm"
else os.home / ".cache/mill/jvm"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This snippet here looks a bit unusual. I thought we just use os.home for most things? Or are we using UserProfile in other parts of the code as well?

Copy link
Collaborator Author

@alexarchambault alexarchambault Apr 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, mill.bat uses it here. I also used it in JLineNativeLoader, added in #4882.

Ideally, that directory should be obtained by a native Windows call rather than via the environment. Coursier does it via directories-jvm, but it's quite cumbersome (requires JNI or newer JVM foreign API stuff, or running a powershell script…). Given mill.bat relies on the env for that, it's better just to do the same in Mill IMO.

@@ -51,6 +53,11 @@ trait JvmWorkerModule extends OfflineSupportModule with CoursierModule {

def zincLogDebug: T[Boolean] = Task.Input(Task.ctx().log.debugEnabled)

def useShortJvmPath(jvmId: String): Boolean =
Properties.isWin && (
jvmId.startsWith("graalvm") || jvmId.startsWith("liberica-nik")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's liberica-nik?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's an alternative GraalVM distribution. Coursier uses it, as it has support for more platforms (like Alpine Linux on arm64, but not Windows on arm64 though)

 Conflicts:
	build.mill
	core/util/src/mill/util/Jvm.scala
	scalalib/src/mill/scalalib/JvmWorkerModule.scala
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants