-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Bundle scala cli in scala command #20351
base: main
Are you sure you want to change the base?
Conversation
1e4a234
to
acbd467
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can only comment on what's jumping at me. The timing is way too short to do a real review.
Even if I did find something it wouldn't get addressed and shipped in time at this point, so, to be blunt: why bother?
Edit: We can not guarantee that the Jar-based launcher works on JDK 17, so this must be |
A question is if a new scala-cli is released, will scala update it automatically, like |
The way it is currently implemented, the idea would be that each scala version is tied to a specific Scala CLI launcher. and Each scala release would come with whatever is the latest Scala CLI version at that moment |
|
cbcd575
to
46696d5
Compare
|
project/DottyVersion.scala
Outdated
|
||
val baseVersion = "3.5.0-RC1" | ||
|
||
val referenceVersion = "3.4.2-RC1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need a rebase
8ee4e6d
to
863b28b
Compare
9c3357f
to
6c9e3f3
Compare
455da81
to
a1291b3
Compare
@hamzaremmal this is everything that was agreed in the plan, except for deciding what to do about the lib directory - and maybe caching the task to populate the local maven2 repo with coursier - also that relies upon cleaning the repo but it seems ci does that anyway (multiple times) We would also need to update the ci.yml to publish artefacts for each launcher - and the sdkman publishing, but perhaps that can be another PR? |
Yes, it should be in another PR with the changes to the launchers.yml workflow too. I will take care of it. |
oh right and we should squash when merging this one I think |
Definitely |
cleanup Build.scala
a1291b3
to
84c6969
Compare
I have manually squashed the commits where it makes sense |
fixes #20098
Proposed changes to zip/targz archive:
/bin
directory store an extra launcher for Scala CLI (either JAR, or native per platform)./bin/scala[.bat]
is modified to invoke Scala CLI stored in/bin
/maven2
directory, which stores all the Jars and POM files necessary (in maven repo style) for scala-cli to invoke scala compiler offline (using the-r
launcher option)./lib
by aliases to the corresponding jar in/maven2
, OR delete/lib
and update references from scripts. (Looks like symlinks are not portable, so probably we should encode the classpath in a file, or adjust slightly how we build the toolchain)scala-3.5.0-x86_64-pc-linux.tar.gz
(for the artefact that bundles the x64 linux launcher)