diff options
Diffstat (limited to 'documentation/building.md')
-rw-r--r-- | documentation/building.md | 28 |
1 files changed, 0 insertions, 28 deletions
diff --git a/documentation/building.md b/documentation/building.md deleted file mode 100644 index 3d806f6..0000000 --- a/documentation/building.md +++ /dev/null @@ -1,28 +0,0 @@ -# Building from source -A complete build of flow involves two parts - - 1. building scala sources (the front-end) - 2. building native sources (the back-end) - -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. - -## 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'. - -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 - - `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 - -Usually (following most linux distribution's conventions), shared libraries produced by a project `name` of version `M.m.p` are named `libname.M.m.p`. However, since when accessing shared libraries through the JVM, only the `name` can be specified and no particular version, the convention adopted by flow is to append `M` to the library name and always keep the major version at zero. E.g. `libflow.3.1.2` becomes `libflow3.0.1.2`. |