update documentation to reflect build refatorings

3 files changed, 15 insertions, 16 deletions

diff --git a/documentation/basics.md b/Documentation/basics.md
index 1982f66..1982f66 100644
--- a/documentation/basics.md
+++ b/Documentation/basics.md
diff --git a/documentation/building.md b/Documentation/building.md
index 3d806f6..6283851 100644
--- a/documentation/building.md
+++ b/Documentation/building.md
@@ -7,20 +7,18 @@ A complete build of flow involves two parts
 As any java or scala project, the first part results in a platform independent artifact. However, the second part yields a binary that may only be used on systems resembling the platform for which it was compiled. Both steps are independent, their only interaction being the header files generated by javah (see `sbt javah` for details), and may therefore be built in part and in any order.
 
 ## Compiling and packaging java/scala sources
-Run `sbt flow/packageBin` in the base directory. This simply compiles any scala and java sources as with any standard sbt project and produces a jar ready for being used.
+Run `sbt main/packageBin` in the base directory. This simply compiles any scala and java sources as with any standard sbt project and produces a jar ready for being used.
 
 ## Compiling and linking native sources
 The back-end is managed by GNU Autotools and all relevant files are contained in 'flow-native'. The first time, run `./bootstrap`, then `./configure && make` to compile the back-end. After completing this step, native libraries for the different platforms are available to be copied and included in end-user applications or installed on the system. To copy the binaries to a local directory, run ```DESTDIR=`pwd`/<directory> make install```. To install them system-wide, simply run `make install` as an administrator.
 
 ## Creating a fat jar
-The native binaries produced in the previous step may be bundled in a "fat" jar so that they can be included in sbt projects through its regular dependency mechanisms. In this process, sbt basically acts as a wrapper script around autotools, calling the native build process and packaging generated binaries. Running `sbt flow-native/packageBin` in the base directory produces the fat jar in 'flow-native-sbt/target'.
+The native binaries produced in the previous step may be bundled in a "fat" jar so that they can be included in sbt projects through its regular dependency mechanisms. In this process, sbt basically acts as a wrapper script around autotools, calling the native build process and packaging generated binaries. Running `sbt native/packageBin` in the base directory produces the fat jar in 'flow-native-sbt/target'.
 
 Note: an important feature of fat jars is to include binaries for several platforms. To copy binaries compiled on other platforms to the fat jar, place them in a subfolder of 'flow-native-sbt/lib_native'. The subfolder should have the name `$(os.name)-$(os.arch)`, where `os.name` and `os.arch` are the java system properties of the respective platforms.
 
 # Note about versioning
-When building and locally publishing projects, the usual convention is to append "-SNAPSHOT" to the version string. This practice however breaks version identification and badly hurts git (bisecting becomes a nightmare). Therefore, to identify a build artifact with a specific commit in the repository, a sha1 hash is appended to the version instead. When publishing a new release, this hash may be ommited by setting the java system property "release=true", simply by running `sbt -Drelease=true`.
-
-A second versioning quirk to be aware of is when building native sources. In this case, the project and package versions follow a sematic pattern: `M.m.p`, where
+A versioning quirk to be aware of is when building native sources. In this case, the project and package versions follow a sematic pattern: `M.m.p`, where
  - `M` is the major version, representing backwards incompatible changes
  - `m` is the minor version, indicating backwards compatible changes such as new feature additions
  - `p` is the patch number, representing internal modifications such as bug-fixes
diff --git a/README.md b/README.md
index 9daccf3..f9fb4ab 100644
--- a/README.md
+++ b/README.md
@@ -4,24 +4,22 @@ Serial communication library for Scala, designed to be reactive, lightweight and
 ## Motivation
 The main reason for yet another serial communication library for the JVM is that all other libraries tested used blocking IO and/or consumed enormous amounts of CPU while being idle. Flow's main goal is therefore to provide a lightweight library that only does work when communication is required. This reactive concept integrates well with the Akka IO layer therefore making flow an ideal library for extending it.
 
-## Basic usage
-For a short guide on how to use flow see the file [documentation/basics.md](documentation/basics.md).
-
+## Dependencies
 Flow is built and its examples run with SBT. To get started, include a dependency to flow in your project:
 
-    libraryDependencies += "com.github.jodersky" %% "flow" % "2.1.0"
+    libraryDependencies += "com.github.jodersky" %% "flow" % "2.1.1"
 
-ATTENTION: flow uses native libraries to back serial communication, therefore before you can run any application depending on flow you must include flow's native library! To do so, you have two options.
+*ATTENTION*: flow uses native libraries to back serial communication, therefore before you can run any application depending on flow you must include flow's native library! To do so, you have two options.
 
 1.  The easy way: add a second dependency to your project:
         
-        libraryDependencies += "com.github.jodersky" % "flow-native" % "2.1.0"
+        libraryDependencies += "com.github.jodersky" % "flow-native" % "2.1.1"
 
     This will add a jar to your classpath containing native libraries for various platforms. At run time, the correct library for the current platform is selected, extracted and loaded. This solution enables running applications seamlessly, as if they were pure JVM applications. However, since the JVM does not enable full determination of the current platform (only OS and rough architecture are known), only a couple of platforms can be supported through this solution at the same time. Currently, these are given in the table below.
 
     | OS                | Architecture         | Notes                                                                  |
     |-------------------|----------------------|------------------------------------------------------------------------|
-    | Linux | x86<br>x86_64<br>ARM (v7, hardfloat ABI) | A user accessing a serial port may need to be in the dialout group <br> ARM may work on other versions too, any feedback is welcome!<br>|
+    | Linux | x86<br>x86_64<br>ARM (v7, hardfloat ABI) | A user accessing a serial port may need to be in the dialout group. |
     | Mac OS X | x86_64               | Use /dev/cu* device instead of /dev/tty*.                              |
 
 
@@ -37,16 +35,19 @@ ATTENTION: flow uses native libraries to back serial communication, therefore be
 
 It is recomended that you use the first option only for testing purposes or end-user applications. The second option is recomended for libraries, since it leaves more choice to the end-user.
 
+## Basic usage
+See [Documentation/basics.md](Documentation/basics.md) for a short guide on using flow.
+
 ## Examples
-Examples on flow's usage are located in the flow-samples directory. The examples may be run by switching to the corresponding project in sbt: `project flow-samples-<sample_name>` and typing `run`. Be sure to connect a serial device before running an example.
+Examples on flow's usage are located in the flow-samples directory. The examples may be run by switching to the corresponding project in sbt: `project samples-<sample_name>` and typing `run`. Be sure to connect a serial device before running an example.
 
-Since flow integrates into the Akka-IO framework, a good resource on its general design is the framework's documentation at http://doc.akka.io/docs/akka/2.3.9/scala/io.html
+Since flow integrates into the Akka-IO framework, a good resource on its general design is the framework's [documentation](http://doc.akka.io/docs/akka/2.3.10/scala/io.html).
 
 ## Native side
 Since hardware is involved in serial communication, a Scala-only solution is not possible. Nevertherless, the native code is kept simple and minimalistic with the burden of dealing with threads left to Scala. The code aims to be POSIX compliant and therefore easily portable.
 
 ## Build
-See detailed documentation in [documentation/building.md](documentation/building.md) on how to build and install flow.
+See detailed documentation in [Documentation/building.md](Documentation/building.md) on how to build and install flow.
 
-## License
+## Copying
 flow is released under the terms of the 3-clause BSD license. See LICENSE for details.