Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/deanwampler/sakescalabuildtool
A simple build tool for Scala code
https://github.com/deanwampler/sakescalabuildtool
Last synced: 3 months ago
JSON representation
A simple build tool for Scala code
- Host: GitHub
- URL: https://github.com/deanwampler/sakescalabuildtool
- Owner: deanwampler
- License: other
- Created: 2009-09-21T15:08:15.000Z (over 15 years ago)
- Default Branch: master
- Last Pushed: 2019-11-29T18:53:17.000Z (about 5 years ago)
- Last Synced: 2023-04-14T23:35:39.916Z (over 1 year ago)
- Language: Scala
- Homepage:
- Size: 16.6 MB
- Stars: 16
- Watchers: 4
- Forks: 3
- Open Issues: 0
-
Metadata Files:
- Readme: README.html
- License: LICENSE
Awesome Lists containing this project
README
Sake Build Tool README
README for Sake: a build tool written in Scala
Dean Wampler
[email protected]
I wrote Sake (pronounced like the Japanese rice beverage) as a learning exercise to experiment with Scala features, like DSL creation. It is inspired by Ruby Rake and Unix Make, hence the name. (I know that there is already a distributed build system for Ruby called Sake...) Sake is used to build the code examples for Programming Scala
Sake is very incomplete and it has plenty of warts. If you want a “production quality” build tool, consider Simple Build Tool (sbt), which uses Scala for build scripts, or Buildr, which uses Ruby scripts, but has built-in support for building Scala code.
Sake is maintained on GitHub.
Getting Started
The distribution is already built, but you can run “bin/sake” to re-build it at any time. (See also the note below.)
It is easiest to copy the whole distribution somewhere useful and then define a SAKE_HOME environment variable that points to that root directory. Follow these steps.
- Copy the distribution somewhere convenient, e.g., /usr/local/sake.
- Define SAKE_HOME, e.g., SAKE_HOME = /usr/local/sake (using appropriate syntax for your shell).
- Add $SAKE_HOME/bin to your path.
To use Sake in a project:
- Create a “sake.scala” file in the root of your project.
- Copy the “sake.scala” contents from the Sake distribution to your sake.scala.
- Edit to taste.
- Copy the versions of Sake's jars that you want to use, either "lib/2.7.7/sake-2.7.7-1.1.jar" or "lib/2.8.0.RC7/sake-2.8.0.RC7-1.1.jar"
- Build with “bin/sake [targets]”, where one or more targets can be specified. (Defaults to “all”.)
Note: To bootstrap sake when there is not a previous version built, use the included Makefile. For example, this will be necessary when upgrading to a newer version of Scala that is not binary compatible with the previous version. (I had to do this when migrating from v2.7.7 to 2.8.0.)
Layout of the Distribution
-
README.txt – This file. - sake.scala – Sake build file that builds sake itself. Used by “bin/sake”
- bin – Directory with the “sake” UNIX shell script and “sake.bat” Windows script.
- build – Directory where build projects are staged.
- lib – Directory of 3rd party libraries necessary to build and use Sake and where the sake jars themselves are also written.
- spec – Directory of “specs” files for testing.
- src – Directory of Sake source code.
History
- December 6, 2008: Created Sake project.
- December 20, 2008: First “bootstrap” build of Sake with itself!
- April 18, 2009: Added sxr to build for generating browsable HTML of the source.
- September 21, 2009: Moved Sake to GitHub.
- July 10, 2010: Ported to Scala v2.8.0.RC7.
TODO
- Add a built-in jar command.
- Add copy and mv/rename commands.
- Add ScalaTest and ScalaCheck commands.
- Support setting environment options through command-line options.
- Provide a way for the user to specify the default target.
- Get “sxr” (http://github.com/harrah/browse/tree/master) to work. It generates a browsable HTML version of the Sake source code. When you compile, it should be written into the “browse” directory, but for some reason it isn’t working. See comments in the “sake.scala” file.
- Interactive Mode:
- Run targets, if specified, after loading file.
- If a target fails, don’t exit!
- Use implicits to convert from strings to symbols where “useful”. Same for A* vs. List[A] ??
- Support using tuples when defining dependencies, where lists are now required.
- Work around the 2.8.0 problem with the scala script driver.
Implementation Notes
- You’ll notice that a lot of types have small, protected methods that are often one liners for creating Files, etc. They could be easily in-lined. Usually, they are there to facilitate testing. A spec can subclass the type under test (TUT) and override the method to return a test double, etc.