mirror of
https://github.com/sbt/sbt.git
synced 2026-10-06 10:03:56 +02:00
Ethan Atkins
df5f9ae3cb
I had previously not though there was much reason to support commands in continuous builds. This was primarily because there were a number of questions regarding semantics. Commands cannot have fileInputs specifically assigned to them because they don't have an associated scope. They also can arbitrarily modify state so what is the expectation when running ~foo where foo is a command that, for example, replaces itself. I settled on the following semantics: 1) Commands run in a continuous build cannot modify the sbt execution state which is to say that the state that is returned by continuous is the same that was passed in (unless a reload occurred or we exited the build with an exception) 2) Any global watchTriggers or fileInputs apply to a watched command. They automatically inherit any fileInputs that are queried when running tasks in a command. So, for example, ~+compile does what you'd expect. The implementation is fairly straightforward. If we can successfully parse a command, but we cannot parse a scopedKey from it, we assign it a private ScopedKey. When computing the watch settings for that key, we will select the global settings through delegation. This is how it picks up the global watchTriggers. To run the command, I had to rework the task evaluation portion because a command may return a state with additional commands to run. The cross build command works this way. We recursively run all of the commands starting with the original until we run out of commands to run. As part of this work, I was able to remove the three argument version of Command.processCommand that I'd previously added to support my old approach to evaluating commands. This was a nice bonus. I added scripted tests that check that global watchTriggers are picked up and that commands that delegate to a command that uses fileInputs automatically pick up those inputs during the watch. I also added a test that approximates the ~+compile use case and ensures that the failure semantics are what we expect and that the task runs for all defined scala versions.
sbt
sbt is a build tool for Scala, Java, and more.
For general documentation, see http://www.scala-sbt.org/.
sbt 1.x
This is the 1.x series of sbt. The source code of sbt is split across several Github repositories, including this one.
- sbt/io hosts
sbt.iomodule. - sbt/util hosts a collection of internally used modules.
- sbt/librarymanagement hosts
sbt.librarymanagementmodule that wraps Ivy. - sbt/zinc hosts Zinc, an incremental compiler for Scala.
- sbt/sbt, this repository hosts modules that implements the build tool.
Other links
- Setup: Describes getting started with the latest binary release.
- FAQ: Explains how to get help and more.
- sbt/sbt-zero-seven: hosts sbt 0.7.7 and earlier versions
Issues and Pull Requests
Please read CONTRIBUTING carefully before opening a GitHub Issue.
The short version: try searching or asking on StackOverflow.
license
See LICENSE.