diff options
Diffstat (limited to 'documentation/building.md')
| -rw-r--r-- | documentation/building.md | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/documentation/building.md b/documentation/building.md index 4c95b85..0f48cf5 100644 --- a/documentation/building.md +++ b/documentation/building.md @@ -13,9 +13,9 @@ Run `sbt flow/packageBin` in the base directory. This simply compiles any scala The back-end is managed by GNU Autotools and all releveant 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/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 flow-native-scala/packageBin` in the base directory produces the fat jar in 'flow-native-scala/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/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.
\ No newline at end of file +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. |