Simplifying the build system

610 views
Skip to first unread message

Sam Tuke

unread,
May 6, 2014, 6:23:23 AM5/6/14
to osm...@googlegroups.com
Hi Guys,

The F-Droid Open Source App Store developers are having a real hard time packaging Osmand; they've actually given up because of difficulties with patching and creating submodules in the process of trying to build new versions.

Do you have plans to simplify the build system soon to make it possible for third parties to build different versions of Osmand from source? Unfortunately it looks like the thousands of F-Droid users will be stuck with the excellent but outdated version 1.5 otherwise.

Here's what one of the lead F-Droid devs said about the issue today: https://f-droid.org/forums/topic/new-version-of-osmand/page/3/#post-11103

For what it's worth, I donated 30€ last year to Osmand and I'd be delighted to do so again if I can get an update through F-Droid.

Best,

Sam.

Saikrishna Arcot

unread,
May 6, 2014, 8:48:35 AM5/6/14
to osm...@googlegroups.com
For what it's worth, I had to spend half a day getting Osmand to actually use native mode. It took a while for me to realize that the Jenkins builders are using the legacy_core branch of Osmand-core, as defined in this file.

Here are the steps I followed to build a (more or less) working Osmand (development version) without using any of the repo stuff and without an IDE (I suspect I'm missing something, because it takes about 2 minutes to give directions):
  1. Run "git clone https://github.com/osmandapp/Osmand.git android"
  2. Run "git clone -b legacy_core https://github.com/osmandapp/OsmAnd-core.git core"
  3. Run "git clone https://github.com/osmandapp/OsmAnd-resources.git resources"
  4. Run "ANDROID_SDK=<path_to_SDK> ANDROID_NDK=<path_to_NDK> android/OsmAnd/old-ndk-build.sh". Replace <path_to_SDK> and <path_to_NDK> with appropriate values. This will build the native libraries.
  5. Change your current directory to android/OsmAnd, and run "ant -file build.xml -Dndk.dir=<path_to_NDK> -Dsdk.dir=<path_to_SDK> -Dbuild.version=<version_code> -Dnativeoff=false "-DversionFeatures=+play_market +gps_status" "-DFEATURES=+play_market +gps_status" debug". Again, replace <path_to_SDK> and <path_to_NDK> with appropriate values. The <version_code> is what will get displayed as the version. This will build the app itself, and will include the native libraries built in the previous step.
  6. To install it onto your device, run "adb install bin/OsmAnd-debug.apk".

Saikrishna Arcot

unread,
May 6, 2014, 9:06:45 AM5/6/14
to osm...@googlegroups.com
I should add that the valid version features in step 5 are defined in android/OsmAnd/src/net/osmand/plus/Version.java. Running "grep -r versionFeatures" should bring up the relevant lines.

Also, the android repo has a r1.7 branch that, I think, corresponds to the official 1.7 release.

I hope this helps F-Droid (and anyone else) simplify the build environment and produce a working version.

Marko Mäkelä

unread,
May 10, 2014, 4:02:50 PM5/10/14
to osm...@googlegroups.com
Tuesday, 6 May 2014 16.06.45 UTC+3 Saikrishna Arcot wrote:
I should add that the valid version features in step 5 are defined in android/OsmAnd/src/net/osmand/plus/Version.java. Running "grep -r versionFeatures" should bring up the relevant lines.

Also, the android repo has a r1.7 branch that, I think, corresponds to the official 1.7 release.

I hope this helps F-Droid (and anyone else) simplify the build environment and produce a working version.

Thanks, this was very much appreciated! It is great that the software can be built without installing Eclipse.

When I was building the system, I got some ideas for improvement:

1. Define the revision in a single repository. Either merge all 3 repositories to one, or define something like svn:externals for the 2 other repositories in the "main" repository.
2. Use a conventional build system for the native code, instead of a Bourne shell script. I would recomment CMake if Ant does not easily support compiling C or C++. (I have limited experience with modern Java, and I develop C/C++ for living.)
3. Allow compiling multiple modules in parallel. With CMake for the native code, you could use make -j$(nprocs). I guess that compiling the Java code without Ant is out of the question.
4. Implement a common configuration interface. Coming outside the Java world, I would suggest cmake -DWITH_FOO:BOOL=ON. Currently there seem to be 2 interfaces: some variables in the *.sh script for the native code, and the versionFeatures for the Java code.
5. Allow more things to be disabled at compilation time: parking plugin, OSM editing, bitmap maps, advertisement for other applications, anything that needs Internet access, and so on.

The last point is most important to me. I am thinking of writing a patch "OsmAnd-" that would disable everything that I do not need. I basically only need offline navigation on offline vector maps, and I can update the map files myself. This should reduce the memory footprint, making OsmAnd run better on an older device. My 3-year-old SonyEricsson Xperia Active still seems to be the best hardware for bicycling, because it is waterproof and can be easily mounted on the handlebar.

 Marko
Reply all
Reply to author
Forward
0 new messages