サマリ

https://github.com/harrah/xsbt/wiki/Getting-Started-Summaryの訳(2011/10/30時点)

Getting Started Summary

• Page History

Previous Getting Started Guide page 14 of 14.

This page wraps up the Getting Started Guide.

To use sbt, there are a small number of concepts you must understand. These have some learning curve, but on the positive side, there isn't much to sbt except these concepts. sbt uses a small core of powerful concepts to do everything it does.

If you've read the whole Getting Started series, now you know what you need to know. sbt: The Core Concepts

• the basics of Scala. It's undeniably helpful to be familiar with Scala syntax. Programming in Scala written by the creator of Scala is a great introduction.
• sbt build definition
  • your build definition is one big list of Setting objects, where a Setting transforms the set of key-value pairs sbt uses to perform tasks.

    to create a Setting, call one of a few methods on a key (the := and <<= methods are particularly important). there is no mutable state, only transformation; for example, a Setting transforms sbt's collection of key-value pairs into a new collection. It doesn't change anything in-place. each setting has a value of a particular type, determined by the key. tasks are special settings where the computation to produce the key's value will be re-run each time you kick off a task. Non-tasks compute the value once, when first loading the build definition.

  Scopes
  • each key may have multiple values, in distinct scopes. scoping may use three axes: configuration, project, and task. scoping allows you to have different behaviors per-project, per-task, or per-configuration. a configuration is a kind of build, such as the main one (Compile) or the test one (Test). the per-project axis also supports "entire build" scope. scopes fall back to or delegate to more general scopes.
• sbt vs. .scala build definition
  • put most of your settings in build.sbt, but use .scala build definition files to define multiple subprojects, and to factor out common values, objects, and methods. the build definition is an sbt project in its own right, rooted in the project directory.
  Plugins are extensions to the build definition
  • add plugins with the addSbtPlugin method in project/build.sbt (NOT build.sbt in the project's base directory).

If any of this leaves you wondering rather than nodding, please ask for help on the mailing list, go back and re-read, or try some experiments in sbt's interactive mode.

Good luck! Advanced Notes

The rest of this wiki consists of deeper dives and less-commonly-needed information.

Since sbt is open source, don't forget you can check out the source code too!