sbt 0.7 makes using a locally built version of Scala easier than previous versions. sbt just needs to know where the library and compiler jars are for this version.

A ScalaInstance object represents a version of Scala, backed by compiler and library jar locations. To get a ScalaInstance for a local Scala, call one of the variants of defineScala:

/** Get a `ScalaInstance` for the Scala version with base directory `home`.  The library and compiler jars are
* assumed to be at `new File(home, "lib/scala-library.jar")` and `new File(home, "lib/scala-compiler.jar")`.
* The label for this instance is determined by the version String in the `compiler.properties` file in `scala-compiler.jar`.*/
def defineScala(home: File): ScalaInstance

/** Get a `ScalaInstance` for the Scala version with base directory `home`.  The library and compiler jars are
* assumed to be at `new File(home, "lib/scala-library.jar")` and `new File(home, "lib/scala-compiler.jar")`.
* `version` is used as the label for this instance.*/
def defineScala(version: String, home: File): ScalaInstance

The label referred to in the comments is how you refer to this version in your build.scala.versions property and in the ++<version> version switching command.

Override the localScala method to declare these local instances to sbt:

override def localScala =
  defineScala("2.8.0-local", new File(scalaRoot + "/build/pack/")) ::
  Nil

Include it in build.scala.versions:

$ cat project/build.properties
...
build.scala.versions=2.8.0.RC2 2.8.0-local 2.7.7
...

or use it temporarily with ++<version>:

$ sbt "++2.8.0-local compile" "++2.7.7 compile"

sbt reuses the class loader for the local Scala version. If you recompile your local Scala version and you are using sbt interactively, run

> reload

to use the new compilation results.

Comment by sethti...@gmail.com, Aug 28, 2009

$SBT_HOME/project/build/src/CrossCompileProject?.scala should be just $SBT_HOME/project/build/CrossCompileProject?.scala

Comment by project member dmhar...@gmail.com, Aug 28, 2009

Thanks! -Mark

Comment by jzaugg, Oct 4, 2009

I'm trying the first method, but it looks like the wrong pattern is being used to search the snapshot repository. How can I configure the correct pattern: http://scala-tools.org/repo-snapshots/[organization]/[module]/2.8.0-SNAPSHOT/[artifact]-[revision].[ext]

[warn]   [SNAPSHOT]
[warn]   -- artifact org.scala-lang#scala-compiler;20091004.003722-+!scala-compiler.jar:
[warn]   http://scala-tools.org/repo-snapshots/org/scala-lang/scala-compiler/[revision]/scala-compiler-[revision].jar

...

[info] == Simple Build Tool / update ==
[error] Error running update: unresolved dependency: org.scala-lang#scala-compiler;20091004.003722-+: not found
[error] unresolved dependency: org.scala-lang#scala-library;20091004.003722-+: not found
[info]

Comment by project member dmhar...@gmail.com, Oct 4, 2009

Make sure you using the 0.5.5 launcher. The ability to specify a specific snapshot was introduced in that version of the launcher. I've updated the page to mention that.

-Mark

Comment by rickyn...@gmail.com, Oct 13, 2009

When I try to do publish-local on a project built with a nightly Scala according to the first method above, sbt complains (in make-pom) that it can't find the scala-library:

error? Error running deliver-local: unresolved dependency: org.scala-lang#scala-library;2.8.0-20091013.004057-+: not found

Comment by felip...@gmail.com, Dec 16, 2009

if you use 2.8.0-SNAPSHOT it will work perfectly. No need to find the specific scala version.

Comment by project member dmhar...@gmail.com, Dec 16, 2009

Sure, until the underlying version you built sbt with is incompatible with the latest nightly. In any case, I think most people on 2.8 are using 0.6.x now, even though it is experimental.

-Mark

Comment by stefan.w...@gmx.de, Feb 23, 2010

I tried to follow these instructions using sbt-launch-0.7.0.jar. The project file can not be compiled because the ScalaInstance? type is not found. I have added the "import sbt." statement.

Comment by project member dmhar...@gmail.com, Feb 23, 2010

Sorry about that. ScalaInstance? is still under the xsbt namespace. You don't actually need to reference it. I've fixed the example.

Note that Scala trunk is currently undergoing classpath changes that mean sbt can't work with it.

-Mark

Comment by stefan.w...@gmx.de, Feb 26, 2010

Hi Mark,

will you inform the sbt users when Scala trunk can be used as a local version again? They recently fixed an important issue for me and I would like to benefit from the fix in my sbt project.

Thanks, --Stefan

Comment by project member dmhar...@gmail.com, Feb 27, 2010

Yes.

Comment by saveferr...@gmail.com, Jul 22, 2010

Hi,

sbt 0.7.4 seems to come pre-packaged retrieve and build on Scala 2.8.0RC2 -- will there be a release to support the (new) Scala 2.8.0-final ?

Thanks -- Dave

Comment by michaelmwu@gmail.com, Oct 8, 2010

I am trying to use a local scala that is defined outside of the project directory, so I have

defineScala("2.8.x-virtualized-SNAPSHOT", new File("../scala-virtualized/build/pack"))::Nil

I can run the compile action fine, but if I try to do test-compile it fails:

Error running test-compile: java.lang.IllegalArgumentException?: requirement failed: Path component cannot be '..'

I tried with another project and publish-local also fails if the localScala is outside the directory.

I also tried absolute paths, like this:

defineScala("2.8.x-virtualized-SNAPSHOT", new File("/Code/scala-virtualized/build/pack"))::Nil

and that does not help either.

This is on Windows.

Comment by michaelmwu@gmail.com, Oct 8, 2010

Looks like I was able to get this to work, with the drive specified.

defineScala("2.8.x-virtualized-SNAPSHOT", new File("C:/Code/scala-virtualized/build/pack"))::Nil