-
Notifications
You must be signed in to change notification settings - Fork 1.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
implement scalac script in Scala #15212
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
6326fb7
to
9f03cf5
Compare
9f03cf5
to
e5abec0
Compare
@michelou also tagging you here for when this is merged |
tested in |
addScala "$1" | ||
shift | ||
;; | ||
-classpath*) |
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.
Same confusion here. This did not use to be special in the old script. Why is it special now?
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.
This is copied from the Scala script, I think there was the same Cygwin bug there
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 don't think it's related to cygwin; the code and comments appear to be inherited from the scala2 version of the script.
"-Dscala.usejavacp=true" \ | ||
"-Dscala.home=$PROG_HOME" \ |
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.
Are these things that the cs runner would be able to pass to MainGenericRunner
?
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.
CS can configure properties, but probably does not have a magic variable for the launch directory (-Dscala.home was copied from the Scala script for use in programs), I don't think it should be supported in CS because the directory structure is not equivalent
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.
Some scripts will fail if -Dscala.home=$PROG_HOME
isn't defined.
And there is no simple alternative to figuring out the path to the current runtime scala.
Different scripts can specify different versions of scala via the hashbang line, so environment variables can't be relied on. See #13758
It might not matter for non-script code, although it can be useful there as well.
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've had a look and we can check if the property coursier.mainJar
is set, which will be the path of the coursier launcher script - we can then use that to set scala.home
to the parent directory. - problem here is that using the native script then scala is at s"${sys.props("scala.home")}/bin/scala"
, but for coursier it is s"${sys.props("scala.home")}/scala"
(we could go one directory above to preserve /bin
but I think this won't work on a custom Coursier install dir. [edit: I checked and for windows the default it also in some /bin
directory])
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.
Idea from @sjrd it could likely be much more useful to provide properties that have the classpath of the scala compiler and scala standard libraries, that can be provided as arguments to the java command, this is more uniform than a fragile directory structure that depends on the package manager.
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 like this suggestion, it would then be possible to find the first scala3-library*.jar in the classpath, and two directories up would be scala.home
.
a8a2bc8
to
98d5f9d
Compare
3b1413b
to
37bcdb3
Compare
This comment was marked as outdated.
This comment was marked as outdated.
37bcdb3
to
e15cfa9
Compare
646cf10
to
7e05e4e
Compare
989327a
to
0529979
Compare
0529979
to
aa554da
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 don't know about the changes with #!/usr/bin/env -S bin/scala
, but otherwise LGTM.
|
||
// won't compile unless the hashbang line sets classpath | ||
import org.jline.terminal.Terminal | ||
import org.jsoup.Jsoup |
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.
for clarification: jline is included in the compiler toolchain by dist/bin/common
, so the -classpath 'dist/target/pack/lib/*'
is not necessary. However Jsoup is in the lib directory, making the import break without it.
aa554da
to
a117aff
Compare
I will open a new PR with the shebang changes (Edit: see #15241) |
Looks good |
do you think we can backport this to the 3.1.3 branch? - It would be good to get this as soon as possible into Coursier's |
fixes #15173
fixes #15221