How to incorporate existing make file with Android NDK

Question

So I have a huge existing C project that I have placed in $PROJECT/jni directory. This project is normally made by running a configure script which creates the Makefiles which then allows the project to be compiled via make.

This project is rather large and has many directories containing source files and header files.

I guess I am missing a fundamental understanding here of how Android.mk is supposed to work. Is it supposed to replace the configure and makefile that is currently used to compile the project? Or would I be incorporating the generated makefile from my configure script into the Android.mk? The examples they provide are rather trivial with only a few source files. My jni directory looks more like:

jni/
  folder1/subfolder1
  folder1/subfolder2
  folder1/source
  folder2/source
  .....
  foldern/source
  configure/
  configure/configure.sh
  Makefile
  Android.mk

The generated makefiles are pretty extensive (good amount of configuration and there is one in every directory) so I am little lost as to how to approach this.

EDIT:

The major issue is that the examples that ship with the NDK are trivial examples. They have 3-5 source files in the top level jni directory. My issue is that this is a huge project with complex configuration with 4 top level folders each with many subdirectories. I cannot simply move the source into the jni folder and run the ndk compiler.

Answer 1

To answer your question, yes Android.mk is the Android build system. Google barely mentions that the "language" of this file is implemented as GNU make macros. The docs want you to describe your project in terms of those macros. They handle all the grungy cross-compilation details. I'm pretty sure Google has taken this approach to improve forward portability of Android.mk files as the development tools evolve.

The upshot is that (and I know you won't want to hear this) the best answer is probably to write a proper NDK Android.mk for your big project from scratch.

This article lays out the same observations I made porting a library of about 800 files and 300k SLOC. Unfortunately I burned almost two weeks reaching the same conclusion: Cross-compilation causes at least some configure scripts to fail (result in erroneous config.h files). I "invented" pretty much the same techniques he's using in the article. But even after I got a clean build, the resulting static library did not work fully. Hours of debugging netted no useful information. [Caveat: I am no kind of config tools expert. A guru probably would have spotted my error. So it goes.] It took me a couple of days to create a clean Android.mk. The resulting library ran all tests first time through. And it has ported cleanly through several revs of development tools.

Unfortunately building a library that uses configure without the auto tools means building your own config.h by hand for the target environment. This might not be as bad as it sounds. IME systems tend to define much more in their configure environments than they actually use. Getting a clear idea of real dependencies may repay the tedious effort during future refactoring.

The summary statement from the article says it all:

Autotool is good only on GNU systems and using it for cross compiling can be really tedious, confusing, error prone or even impossible. The method described here is a hack and should be used at your own risk.

Sorry I don't have a more positive suggestion.