sbt build

The Scala language is moving to the Simple Build Tool. This change entails a paradigm shift in the way the build is constructed, but should be as unobtrusive as possible for development.

This page captures the basics of using the new build for Scala.

The Basics

On the xsbt branch, you can find the new build definition for Scala. To start up the build, run ./xsbt in the Scala project directory in the xsbt branch. This will download the nightly of SBT 0.10.2, which is required for the Scala build. If there are any errors, you may need to checkout and push-local your own SBT nightly.

Once the project has started, you can run commands on the default root project, including:

• locker-lock - This will compile an instance of the scala compiler used for development and prevent this version from being recompiled during future commands.
• locker-unlock - This will 'unlock' the 'locker' version of the scala compiler so it will get recompiled during development.
• compile - This will compile all source code that's part of a standard distribution, including continuations, swing, actors, etc.
• test - This will run Scala's partest testing suite against all tests, including continuations test. This task will also run 'stability' checks, where-in the scala library and compiler are compiled using the 'quick' version of the compiler to ensure the generated class files are byte-for-byte equivalent.
• doc - This will generate scaladoc HTML for all source code included in the scala-library.jar file.
• package - This will generate all .jar files included in the scala distribution.
• publish-local - This will publish the current version of scala into your local ~/.ivy2 directory.
• publish - This will publish (remotely) the current version of Scala.
• make-dist - This will make a scala 'mini'-distribution, suitable for linux (currently).

A few details

The Scala SBT build is composed of many many subprojects. The root project should provide all the necessary commands for general Scala development (please ask if you see one missing). However, it may be desired to run particular commands on various projects.

For example, if I wanted to run a scala REPL against the actors library while I was doing development, I can run the following command: actors/console or actors/compile:console. The basic gist is that if you feel SBT is doing too much work for your current development, then you will most likely be able to run a subset of commands to isolate a particular task and ensure rapid iteration.

To find a list of available project, just run projects. The projects have been named as close to intuitively as possible. Again, if you're unsure how to do something, just ask.

The Magic Kingdom (layered building)

Scala is bootstrapped from itself. That is, the compiler uses a previous version of the compiler to compile the next version. This will outline what the various layers represent.

• STARR - This is the stable archive reference of Scala. It is an in-between Scala compiler release version that is used for bootstrapping. This is a binary artifact.
• Locker - This is the first instance of Scala compiled from STARR. Locker is designed to be a more-up-to-date version of Scala that can be used for bootstrapping. Locker can be recompiled as needed and locked down for quick development. When experiencing strange build failures, it's sometimes necessary to clean locker and rebuild all layers. Locker is compiled from STARR.
• quick - This is the under-development version of Scala. It is always built, and its binaries become a Scala distribution. This is also the version of Scala used to compile peripheral libraries to the standard library and compiler, like partest, actors, swing, continuations, etc.
• strapp - This is a version of Scala built from quick solely for the purpose of testing binary equivalence. Strapp's class files are compared byte-for-byte against quick. If there are any discrepancies (meaning that Scala's build process is unstable), then the test suite will fail.

In the SBT build, the minimum amount of code is compiled in this bootstrapping process. In the future, as more of the standard library is used in the compiler, more things may need to be available in each layer. Since locker did not include actors in the ant build file, SBT has mimicked this and tried to speed up build times by making actors/swing/dbc only build against quick and only when running the full test suite or packaging.

todos

These are the list of things that need to be fixed before switching from ant to SBT. Things that are not must-have can be pushed back until after the github move.

Must Haves

• Fix for regex issue when running scaladoc.
  • For some reason, our unicode characters are getting parsed differently, it seems. IndexedOutOfBounds on regex replacement.
• Fix the partest artifact to actually depend on the scalaCompiler artifact (at least in maven POMs)
  • Currently causes strange attempt to download scala 2.10-SNAPSHOT....
• scalacheck partest suite (built from scalatest release branch or nightly)
  • May require SBT modifications to allow overriding Settings on reference projects.
• Building a new STARR (and publishing for github move)
• Cleaning fixes
  • Levels of cleaning. full-clean to remove everything in target/ perhaps, and others.
  • Choose the 'right' projects to clean for default clean
• Double-check from-scratch ./xsbt test dist publish-local works without Permgen Errors
  • Note: This might not be a must-have if we can just clean then ./xsbt compile && ./xsbt test && ./xsbt publish-local
• Unique Version (for locker/quick + compile-interface)
  • Akin to the SVN revision number, but possibly a different UUID that we can use for STARR.
• Licensing info in generated pom.xml files.

Desirable Features/Fixes

• incremental/single test run (w/ autocomplete on partest test names) [ 75% Done]
• scalatest/specs2 testing infrastructure