New in Scala 2.9.1 is the -Yrepl-sync option, which prevents each REPL line from being run in a new thread:
scala -Yrepl-sync
When I run console from sbt, how do I have it pass this in?
Short answer:
set scalacOptions in (Compile, console) += "-Yrepl-sync"
How to discover this:
~/code/scratch/20110930 sbt
[info] Loading global plugins from /Users/jason/.sbt11/plugins
[info] Set current project to default-9c7c16 (in build file:/Users/jason/code/scratch/20110930/)
> inspect console
[info] Task: Unit
[info] Description:
[info] Starts the Scala interpreter with the project classes on the classpath.
[info] Provided by:
[info] {file:/Users/jason/code/scratch/20110930/}default-9c7c16/compile:console
[info] Dependencies:
[info] compile:compilers(for console)
[info] compile:full-classpath
[info] compile:scalac-options(for console)
[info] compile:initial-commands(for console)
[info] compile:streams(for console)
[info] Delegates:
[info] compile:console
[info] *:console
[info] {.}/compile:console
[info] {.}/*:console
[info] */compile:console
[info] */*:console
[info] Related:
[info] test:console
> set scalaVersion := "2.9.1"
[info] Reapplying settings...
[info] Set current project to default-9c7c16 (in build file:/Users/jason/code/scratch/20110930/)
> set scalacOptions in (Compile, console) += "-Yrepl-sync"
[info] Reapplying settings...
[info] Set current project to default-9c7c16 (in build file:/Users/jason/code/scratch/20110930/)
> console
[info] Updating {file:/Users/jason/code/scratch/20110930/}default-9c7c16...
[info] Done updating.
[info] Starting scala interpreter...
[info]
Welcome to Scala version 2.9.1.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_26).
Type in expressions to have them evaluated.
Type :help for more information.
scala> :power
** Power User mode enabled - BEEP BOOP SPIZ **
** :phase has been set to 'typer'. **
** scala.tools.nsc._ has been imported **
** global._ and definitions._ also imported **
** Try :help, vals.<tab>, power.<tab> **
scala> settings
res1: scala.tools.nsc.Settings =
Settings {
-classpath = /Users/jason/code/scratch/20110930/target/scala-2.9.1/classes:/Users/jason/.sbt11/boot/scala-2.9.1/lib/scala-compiler.jar:/Users/jason/.sbt11/boot/scala-2.9.1/lib/jansi.jar:/Users/jason/.sbt11/boot/scala-2.9.1/lib/jline.jar
-d = .
-Yrepl-sync = true
-encoding = UTF-8
-bootclasspath = /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsfd.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar:/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/Resources/Java/JavaRuntimeSupport.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/laf.jar:/System/Librar...
Related
sbt defines the organizationName setting as SettingKey[String] (see Keys). When starting an sbt build in an empty directory, one can inspect the default value of organizationName:
> inspect organizationName
[info] Setting: java.lang.String = default
[info] Description:
[info] Organization full/formal name.
[info] Provided by:
[info] {file:/Users/bene/workspace/sbt/test/}test/*:organizationName
[info] Defined at:
[info] (sbt.Classpaths) Defaults.scala:1174
[info] Dependencies:
[info] *:organization
[info] Reverse dependencies:
[info] *:projectInfo
[info] Delegates:
[info] *:organizationName
[info] {.}/*:organizationName
[info] */*:organizationName
So the organizationName setting defaults to "default". Now the question is, where is the default value coming from?
Although it may not be completely obvious, all the information is already there. The sbt output gives us a first hint:
[info] Defined at:
[info] (sbt.Classpaths) Defaults.scala:1174
In line 1174 in Default.scala we can see, that organizationName falls back to the value of organization. Inspecting the organization setting gives us the next hint:
> inspect organization
[info] Setting: java.lang.String = default
[info] Description:
[info] Organization/group ID.
[info] Provided by:
[info] {file:/Users/bene/workspace/sbt/test/}test/*:organization
[info] Defined at:
[info] (sbt.Classpaths) Defaults.scala:1173
[info] (sbt.Build) Build.scala:58
[info] Dependencies:
[info] *:normalizedName
[info] *:thisProject
[info] Reverse dependencies:
[info] *:organizationName
[info] *:projectId
[info] Delegates:
[info] *:organization
[info] {.}/*:organization
[info] */*:organization
Finally, in Build.scala:58 we can find the mapping from a missing organization to "default".
build.sbt
scalaVersion := "2.11.4"
project/build.properties
sbt.version=0.13.7
Then
> show scalaVersion
[info] 2.11.4
> show crossScalaVersions
[info] List(2.10.4)
> inspect crossScalaVersions
[info] Setting: scala.collection.Seq[java.lang.String] = List(2.10.4)
[info] Description:
[info] The versions of Scala used when cross-building.
[info] Provided by:
[info] */*:crossScalaVersions
[info] Defined at:
[info] (sbt.Defaults) Defaults.scala:237
[info] Delegates:
[info] *:crossScalaVersions
[info] {.}/*:crossScalaVersions
[info] */*:crossScalaVersions
[info] Related:
[info] */*:crossScalaVersions
It seems like crossScalaVersions should be List(2.11.4).
Look at SBT's source code, that's also what I would think.
crossScalaVersions := Seq(scalaVersion.value)
Why doesn't crossScalaVersions correspond to scalaVersion?
scalaVersion.value is context-dependent. So in Defaults.scala it's */*:scalaVersion from appConfiguration.value.provider.scalaProvider. It's the version used to compile your project's definition, including your build.sbt file (sbt 0.13.7 uses 2.10.4 scala-compiler to compile your project definitions). And that the only way as your project's definitions (including scalaVersion) isn't compiled yet when Defaults executed and crossScalaVersions defined. So, */*:crossScalaVersions depends on */*:scalaVersion not proj/*:scalaVersion.
Just compare Provided by with explicit scalaVersion := 2.11.4 inside build.sbt:
> inspect scalaVersion
[info] Setting: java.lang.String = 2.11.4
[info] Description:
[info] The version of Scala used for building.
[info] Provided by:
[info] {file:/Users/user/dev/proj/}proj/*:scalaVersion
[info] Defined at:
[info] /Users/user/dev/proj/build.sbt:1
[info] Reverse dependencies (D=derives):
[info] *:allDependencies
[info] D *:scalaBinaryVersion
[info] *:libraryDependencies
[info] *:scalaInstance
[info] *:crossScalaVersions
[info] *:update
[info] Delegates:
[info] *:scalaVersion
[info] {.}/*:scalaVersion
[info] */*:scalaVersion
[info] Related:
[info] */*:scalaVersion
And without one (just empty project):
> inspect scalaVersion
[info] Setting: java.lang.String = 2.10.4
[info] Description:
[info] The version of Scala used for building.
[info] Provided by:
[info] */*:scalaVersion
[info] Defined at:
[info] (sbt.Defaults) Defaults.scala:232
[info] Reverse dependencies:
[info] *:allDependencies
[info] *:libraryDependencies
[info] *:update
[info] *:scalaInstance
[info] Delegates:
[info] *:scalaVersion
[info] {.}/*:scalaVersion
[info] */*:scalaVersion
[info] Related:
[info] */*:scalaVersion
So, you just need to redefine */*:scalaVersion in your build.sbt:
scalaVersion in GlobalScope := "2.11.2"
What is the difference between scalaSource and sourceDirectories? I have a non-standard directory structure where source code lives in src/,
This line works in build.sbt:
scalaSource in Compile := file("src/")
but not
sourceDirectories in Compile := Seq(file("src/"))
Sources come in many kinds: Scala and Java, managed and unmanaged. sourceDirectories in Compile combines all of them, but you wouldn't normally want to set it directly; normally you'd set the more specific setting that applies to the particular kind of source you're trying to tell sbt the location of.
Note that baseDirectory.value / "src" would be more correct than file("src") (it works in more scenarios: subprojects, external projects, etc).
I can't tell you the whole picture, someone who worked on sbt may see this post later.
Till then, here is how I reason about this things: inspect
> inspect actual compile:scalaSource
[info] Description:
[info] Default Scala source directory.
[info] Dependencies:
[info] compile:sourceDirectory
[info] Reverse dependencies:
[info] compile:unmanagedSourceDirectories
[info] Delegates:
[info] compile:scalaSource
> inspect actual compile:sourceDirectories
[info] Description:
[info] List of all source directories, both managed and unmanaged.
[info] Dependencies:
[info] compile:unmanagedSourceDirectories
[info] compile:managedSourceDirectories
[info] Delegates:
[info] compile:sourceDirectories
[info] *:sourceDirectories
[info] {.}/compile:sourceDirectories
Now this is how I interpret this:
sourceDirectories are ... well ... completely informal ...
Lets see how this is relevant to something like compile:
> inspect compile
[info] Dependencies:
[info] compile:compile::compileInputs <----
[info] compile:compile::streams
> inspect compile:compile::compileInputs
[info] Dependencies:
...
[info] compile:compile::sources <----
...
> inspect compile:compile::sources
[info] Provided by:
[info] {file:<build-uri>}<project-id>/compile:sources
[info] Delegates:
[info] compile:compile::sources
[info] compile:sources <----
This task is delegated, we can see where we came from in Reverse dependencies with inspect actual, regular inspect woudn't show them.
> inspect actual compile:sources
[info] Description:
[info] All sources, both managed and unmanaged.
[info] Reverse dependencies:
[info] compile:doc
[info] compile:compile::compileInputs
[info] Dependencies:
[info] compile:unmanagedSources <----
[info] compile:managedSources
> inspect compile:unmanagedSources
[info] Dependencies:
[info] compile:unmanagedSourceDirectories
...
> inspect compile:unmanagedSourceDirectories
[info] Dependencies:
[info] compile:javaSource
[info] compile:scalaSource <----
[info] Reverse dependencies:
[info] compile:sourceDirectories
[info] compile:unmanagedSources
Hope this helps.
My build is simple:
lazy val stampleWebProject = play.Project("stample-web", appVersion, appDependencies,path = file("stample-web"))
.dependsOn(stampleCoreProject,stampleSearchProject)
.aggregate(stampleCoreProject,stampleSearchProject)
lazy val stampleCoreProject = Project(id = "stample-core",base = file("stample-core"))
lazy val stampleSearchProject = Project(id = "stample-search",base = file("stample-search"))
All these projects have a build.sbt file with dependencies, without any scala build (which would be ignored as far as I know)
When I start SBT (12.4), I get the following:
[info] Set current project to stample-core (in build file:/home/sebastien/Bureau/Stample/)
> projects
[info] In file:/home/sebastien/Bureau/Stample/
[info] * stample-core
[info] stample-search
[info] stample-web
> project stample-search
[info] Set current project to stample-search (in build file:/home/sebastien/Bureau/Stample/)
> projects
[info] In file:/home/sebastien/Bureau/Stample/
[info] stample-core
[info] * stample-search
[info] stample-web
> project stample-core
[info] Set current project to stample-core (in build file:/home/sebastien/Bureau/Stample/)
> projects
[info] In file:/home/sebastien/Bureau/Stample/
[info] * stample-core
[info] stample-search
[info] stample-web
> project stample-web
[info] Set current project to stample-search (in build file:/home/sebastien/Bureau/Stample/)
[stample-search] $ projects
[info] In file:/home/sebastien/Bureau/Stample/
[info] stample-core
[info] stample-search
[info] * stample-web
[stample-search] $ compile
[info] Updating {file:/home/sebastien/Bureau/Stample/}stample-core...
[info] Resolving org.slf4j#slf4j-api;1.6.6 ...
[info] Done updating.
[info] Updating {file:/home/sebastien/Bureau/Stample/}stample-web...
[error] a module is not authorized to depend on itself: stample-search#stample-search_2.10;1.0
[error] (stample-web/*:update) java.lang.IllegalArgumentException: a module is not authorized to depend on itself: stample-search#stample-search_2.10;1.0
[error] Total time: 1 s, completed 26 août 2013 21:57:45
I do not understand some stuff here:
How is choosen the project in which we are by default. I've seem documentation was added in SBT 13.0 but did not see it in the 12.4 multibuild documentation.
How comes I type project stample-web and it tells me I'm in stample-search
Why is there a special display in my sbt console for the project I'm in (stample-web or stample-search, I don't really know...) (this appears here: [stample-search] $ compile, is this relative to play projects?
Why it can't compile stample-search, since it doesn't depend on itself in my build (I suspect it tries to compile the web project but there's a naming problem or something?
Is this an SBT bug. If so, is it possible to use the new 13.0 version with Play framework?
Eugene Yokota is right: I have a conflict in the stample-web folder, which was set the stample-web name in the scala build, but it has a wrong build.sbt in the folder which has name := stample-search
When using the Scala interpreter, one could start it with an option like:
C:\Users\John>scala -unchecked
Welcome to Scala version 2.9.2 (Java HotSpot(TM) Client VM, Java 1.6.0_32).
Type in expressions to have them evaluated.
Type :help for more information.
scala>
When using sbt, how can one start the Scala interpreter with options ?
The following try will not work:
C:\Users\John\Test Scala Project 1>sbt
[...]
[info] Loading global plugins from C:\Users\John\.sbt\plugins
[info] Set current project to default-8d4ecc (in build file:/C:/Users/John/Tes
t%20Scala%20Project%201/)
> console -unchecked
[error] Expected end of input.
[error] console -unchecked
[error] ^
With Google & Co I could not figure out how to do this from within the sbt shell. Does anyone know ?
dcs#shadowfax:~/github/ConwayLife (master *)$ sbt
[info] Loading global plugins from /home/dcs/.sbt/plugins/project
[info] Loading global plugins from /home/dcs/.sbt/plugins
[info] Loading project definition from /home/dcs/github/ConwayLife/project
[info] Set current project to default-0d85ea (in build file:/home/dcs/github/ConwayLife/)
default-0d85ea:master>set scalacOptions += "-unchecked"
[info] Reapplying settings...
[info] Set current project to default-0d85ea (in build file:/home/dcs/github/ConwayLife/)