From 888a0f4614724030b46e6e75933573d013224ac6 Mon Sep 17 00:00:00 2001 From: Jakob Odersky Date: Mon, 8 Jul 2013 12:53:23 +0200 Subject: fix typos --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'README.md') diff --git a/README.md b/README.md index 4598e2c..2abd809 100644 --- a/README.md +++ b/README.md @@ -36,7 +36,8 @@ As any java project, the first part results in a platform independant artifact. ├── flow-binaries ├── flow-main ├── flow-native - │   ├── include + │   ├── shared + │ │ └── include │   └── unix ├── flow-samples └── project @@ -48,7 +49,7 @@ The directories of interest in a build are: - flow-native: Contains native sources used in combination with JNI to support interacting with serial hardware. The directory itself is subdivided into: - - include: + - shared/include: general headers describing the native side of the serial API - unix: source code implementing the native serial API for unix-like operating systems @@ -64,14 +65,13 @@ With this structure in mind, building a complete distribution of flow involves ( 2. compiling and linking native sources for the current platform: `flow-native-/native:link` This is the most complicated and error-prone step in the build. It involves running javah to generate JNI headers, compiling the native sources for the current platform and linking them. - Note that for this step to work, a project for the current operating system has to be defined. Take a look at the build file to - see how this is done. + Note that for this step to work, a project for the current operating system has to be defined. Take a look at the build file to see how this is done. 3. locally publishing the native binary to include in final jar: `flow-native-/publishNative` This copies the compiled binary (for the current platform) to the flow-binaries folder. 4. packaging the final jar: `flow/package` - This copies the latest version-compatible shared libraries of flow-binaries to the final jar. + This copies the latest major version-compatible shared libraries of flow-binaries to the final jar. The idea behind publishing to an intermediate location is to provide a central collection of binaries that may be created from different systems and included in one final jar (a nice corollary is that anyone can compile native sources on a platform, submit a pull request and have the binary included). As such, if you are only modifying java/scala sources, it is not necessary to compile any native sources and steps 2 and 3 from above may be omitted. -- cgit v1.2.3