From 1ef2bcff0af8f9fa8823239973bc0b6fa41edaf2 Mon Sep 17 00:00:00 2001 From: Mark Harrah Date: Thu, 2 Jun 2011 18:35:25 -0400 Subject: [PATCH] update README for 0.10.0 --- README.md | 29 +++++++++++--------------- notes | 62 ------------------------------------------------------- 2 files changed, 12 insertions(+), 79 deletions(-) delete mode 100644 notes diff --git a/README.md b/README.md index 5ad365d4b..29f0c60eb 100644 --- a/README.md +++ b/README.md @@ -1,34 +1,29 @@ -[Google Code project]: http://code.google.com/p/simple-build-tool +[Google Code]: http://code.google.com/p/simple-build-tool [Northeast Scala Symposium]: http://www.nescala.org/2011/ [documentation]: https://github.com/harrah/xsbt/wiki [Setup]: https://github.com/harrah/xsbt/wiki/Setup [video of a demo]: http://vimeo.com/20263617 -# sbt 0.9 +# sbt 0.10 -This is the 0.9.x development series of sbt. See [Setup] for getting started with the latest binary release or see below to build from source. +This is the 0.10.x series of sbt. See [Setup] for getting started with the latest binary release or see below to build from source. -The current stable release of sbt is 0.7.7, which can be downloaded from the [Google Code project]. +The previous stable release of sbt was 0.7.7, which was hosted on [Google Code]. -There is a [video of a demo] given at the [Northeast Scala Symposium] that gives a brief introduction to ideas in sbt 0.9. Note that the demo was based on 0.9.0 and things have changed since then. See the [documentation] for current information. +There is a [video of a demo] given at the [Northeast Scala Symposium] that gives a brief introduction to the concepts in sbt 0.9 and later. Note that the demo was based on 0.9.0 and things have changed since then. See the [documentation] for current information. # Build from source To build from source, get the latest stable version of sbt (above) and get the code. - $ git clone -n git://github.com/harrah/xsbt.git + $ git clone git://github.com/harrah/xsbt.git $ cd xsbt -The '-n' option is strictly only necessary when using msysgit on Windows. -(This works around an issue with spaces in the 'master' branch by not checking the 'master' branch out initially.) +The initial branch is the development branch 0.10, which contains the latest code for the 0.10.x series. -The latest tag for 0.9.x is 0.9.10: +The latest tag for 0.10.x is 0.10.0: - $ git checkout v0.9.10 - -Or, get the development branch for 0.9.x: - - $ git checkout 0.9 + $ git checkout v0.10.0 To build: @@ -36,8 +31,8 @@ To build: Copy your stable ~/bin/sbt script to ~/bin/xsbt and change it to use the launcher at: - /target/sbt-launch-0.9.10.jar + /target/sbt-launch-0.10.0.jar -If using the 0.9 development branch, the launcher is at: +If using the 0.10 development branch, the launcher is at: - /target/sbt-launch-0.10.0-SNAPSHOT.jar + /target/sbt-launch-0.10.1-SNAPSHOT.jar diff --git a/notes b/notes deleted file mode 100644 index 83d6d29f9..000000000 --- a/notes +++ /dev/null @@ -1,62 +0,0 @@ -Issues moving Launcher to 2.8: - creating an Array requires a Manifest, which brings in 40k of classes in scala.reflect - scala.package$ is 3k (import scala.collection.immutable.List) and brings in scala.xml - RichInt 2k. scala.collection.mutable.StringBuilder.ensureCapacity uses it (max), which is needed for string concat - scala.xml brings in 50k of classes - scala.math brought in 30k, can't remove because RichInt apparently uses it - 100k additional size adds 50ms to startup time (on my faster machine) - difference between classpaths a) just launcher jar b) current directory + launcher jar is that b) is 50 ms slower than a) - was able to return to old size by enabling optimize/obfuscate phases of ProGuard - -- script tasks (in 'scripts' branch). To use: - 1) add implementation of jsr223 to project/build/lib, declare in project/plugins, or add to sbt startup classpath - 2) Mix sbt.scripts.Scripts into your project definition - 3) Create project/scripts/name.ext - 4) Run as 'name' - 5) To work with dependencies, get the task from the scriptedTasks map by name. Ex: - lazy val myTask = task { ... } dependsOn scriptedTasks("myscript"). - - - added experimental 'sbt-update version [output.jar]' command enabled by mixing in UpdateSbt trait. It probably doesn't work on Windows, but confirmation either way would be helpful. - Changes 'sbt.version' after verifying the version is valid by downloading that version of sbt. - Updates the current launcher jar or the location specified in the second argument with either a downloaded sbt-launch-.jar if available or a copy of the current launcher jar that uses by default when starting new projects. - -TODO: - - tasks as promises - - aggressive recompilation - - API API. Read, write, search API. - - source build system - - - launcher interface versioning - - allow comments in datatype definition file - - tests for API extractor - - have background triggered commands (~sync) - -Task engine -- method tasks will be normal tasks that pull the command line from a CommandLine task -- per task configuration, including logging (e.g. 'task compile log debug') -- unnamed tasks log to parent task -- better control over parallel logging. Approach undecided. Some possibilities: - + optionally one task always logging - + log each task to a file - + interactive control over logging (might require tasks that use console to be explicit in their dependence on the console) - -- should be able to connect one preprocessor to another - -- Interfaces subproject that depends on no other project and defines interfaces in package xsbti. They are written in Java and cannot refer to Scala classes (compileOrder = JavaThenScala). These interfaces can be used to pass objects across ClassLoader boundaries. -- launcher/main interface is not static (no system properties should be used past the static entry point) -- simple, well-defined ClassLoaders -- use Exceptions instead of Option/Either -- every component gets its own subproject -- can use any version of compiler/Scala that is source compatible with the compiler-interface component -- build xsbt using normal cross-build conventions -- compiler: raw interface (no dependency analysis, but still in same jvm) or with dependency analysis -- compiler: can specify scala-library.jar and scala-compiler.jar + version instead of retrieving the ClassLoader -- compiler: new phase that extracts API defined in sources (classes, their members, and all type information) -- minimal dependence on main xsbt logger from subcomponents: use thin interface for subcomponents - -Dependency Management -- resolvers are completely defined in project definition (use Resolver.withDefaultResolvers) -- configurations completely defined within project (use ModuleConfiguration.configurations) - -Launcher -- see launch.specification \ No newline at end of file