Skip to content

Latest commit

 

History

History
21 lines (14 loc) · 2.57 KB

building.md

File metadata and controls

21 lines (14 loc) · 2.57 KB

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 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'.

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.