sbtはプロジェクトのためにScalaを取得する必要があり、自動的に行うことも、明示的に構成することもできます。プロジェクトに対して構成されたScalaのバージョンは、プロジェクトコードのコンパイル、実行、ドキュメント化、REPLの提供を行います。プロジェクトをコンパイルする際、sbtはScalaコンパイラを実行し、リフレクションjarなどの複数のScala jarを含む可能性のあるクラスパスをコンパイラに提供する必要があります。
最も一般的なケースは、リポジトリで使用可能なScalaのバージョンを使用したい場合です。必要な構成は、使用するScalaのバージョンだけです。例えば、
scalaVersion := "2.10.0"
これは、resolvers設定を介して構成されたリポジトリからScalaを取得します。プロジェクトのビルド（コンパイル、実行、scaladoc、REPL）にはこのバージョンが使用されます。
デフォルトでは、標準のScalaライブラリは自動的に依存関係として追加されます。デフォルトとは異なる方法で構成したい場合、またはJavaソースのみのプロジェクトがある場合は、次のように設定します。
autoScalaLibrary := false
Scalaソースをコンパイルするには、Scalaライブラリをクラスパスに含める必要があります。autoScalaLibraryがtrueの場合、Scalaライブラリはすべてのクラスパス（テスト、ランタイム、コンパイル）に含まれます。それ以外の場合は、他の依存関係と同様に追加する必要があります。例えば、次の依存関係定義は、テストのみにScalaを使用します。
autoScalaLibrary := false
libraryDependencies += "org.scala-lang" % "scala-library" % scalaVersion.value % "test"
標準ライブラリ以外のScala依存関係を使用する場合は、通常の管理対象依存関係として追加します。例えば、Scalaコンパイラに依存するには、
libraryDependencies += "org.scala-lang" % "scala-compiler" % scalaVersion.value
これは、前のセクションで説明したautoScalaLibrary設定の値に関係なく必要です。
Scalaコードをコンパイルし、scaladocを実行し、Scala REPLを提供するには、sbtはscala-compiler jarが必要です。これはプロジェクトの通常の依存関係ではないため、sbtは特別なプライベートscala-tool構成でscala-compilerへの依存関係を追加します。状況によっては、これにより詳細な制御を行うことが望ましい場合があります。この自動動作は、managedScalaInstanceキーで無効にします。
managedScalaInstance := false
これにより、scala-libraryへの自動依存関係も無効になります。Scalaコンパイラを何も必要としない場合（コンパイル、REPL、scaladocなど）、ここで停止できます。その場合、sbtはプロジェクトにScalaのインスタンスを必要としません。それ以外の場合は、sbtはコンパイルやその他のタスクのためにScalaコンパイラのjarへのアクセスが必要になります。これらは、scala-tool構成で依存関係を宣言するか、scalaInstanceを明示的に定義することで提供できます。
最初のケースでは、scala-tool構成を追加し、この構成でscala-compilerへの依存関係を追加します。組織は重要ではありませんが、sbtはそれらのjarを適切に処理するために、モジュール名をscala-compilerとscala-libraryにする必要があります。例えば、
managedScalaInstance := false
// Add the configuration for the dependencies on Scala tool jars
// You can also use a manually constructed configuration like:
// config("scala-tool").hide
ivyConfigurations += Configurations.ScalaTool
// Add the usual dependency on the library as well on the compiler in the
// 'scala-tool' configuration
libraryDependencies ++= Seq(
"org.scala-lang" % "scala-library" % scalaVersion.value,
"org.scala-lang" % "scala-compiler" % scalaVersion.value % "scala-tool"
)
2番目のケースでは、ScalaInstance型の値を（通常はコンパニオンオブジェクトのメソッドを使用して）直接構築し、それをscalaInstanceに割り当てます。Scalaソースをコンパイルして実行するには、クラスパスにscala-library jarを追加する必要もあります。例えば、
managedScalaInstance := false
scalaInstance := ...
Compile / unmanagedJars += scalaInstance.value.libraryJar
ローカルでビルドしたScalaバージョンを使用するには、次のセクションで説明されているようにScalaホームを構成します。Scalaは以前と同様に解決されますが、jarは構成されたScalaホームディレクトリから取得されます。
ソースからScalaをビルドした結果は、Scalaライブラリ、コンパイラ、その他のjarを含むサブディレクトリlib/を含むScalaホームディレクトリ<base>/build/pack/です。同じディレクトリレイアウトは、Scalaディストリビューションをダウンロードして展開することによって取得されます。このようなScalaホームディレクトリは、scalaHomeを設定することでjarのソースとして使用できます。例えば、
scalaHome := Some(file("/home/user/scala-2.10/"))
デフォルトでは、lib/scala-library.jarはアンマネージドクラスパスに追加され、lib/scala-compiler.jarはScalaソースのコンパイルとScala REPLの提供に使用されます。scala-libraryには管理対象依存関係は記録されません。これは、Scalaに明示的に依存関係を定義するか、依存関係を介して間接的にScalaに依存する場合にのみ、Scalaがリポジトリから解決されることを意味します。これらの場合、解決された依存関係のアーティファクトは、Scalaホームlib/ディレクトリのjarに置き換えられます。
例として、scalaHomeが構成されている場合にscala-reflectへの依存関係を追加することを検討してください。
scalaHome := Some(file("/home/user/scala-2.10/"))
libraryDependencies += "org.scala-lang" % "scala-reflect" % scalaVersion.value
これは通常どおり解決されますが、sbtは/home/user/scala-2.10/lib/scala-reflect.jarが存在するかどうかを確認します。存在する場合は、管理対象依存関係からのアーティファクトの代わりにそのファイルが使用されます。
Scala jarへの管理対象依存関係を追加する代わりに、直接追加できます。scalaInstanceタスクは、Scalaディストリビューションへの構造化されたアクセスを提供します。例えば、Scalaホームlib/ディレクトリのすべてのjarを追加するには、
scalaHome := Some(file("/home/user/scala-2.10/"))
Compile / unmanagedJars ++= scalaInstance.value.jars
一部のjarのみを追加するには、追加する前にscalaInstanceからjarをフィルターします。
sbtは、Scalaで記述されているため、自身を実行するためにScala jarを必要としています。sbtは、プロジェクトのために記述するビルド定義をコンパイルするために、同じバージョンのScalaを使用します。これはsbt APIを使用するためです。このScalaのバージョンは、特定のsbtリリースに対して固定されており、変更することはできません。sbt 1.9.8の場合、このバージョンはScala 2.12.18です。このScalaバージョンはsbtが実行される前に必要になるため、このバージョンを取得するために使用されるリポジトリは、sbt ランチャーで構成されています。
