eee1675aa4
This gets rid of the 'sources' directory and allows all sources of a given Android application to be in the same directory tree without using a symlink trick. Note that apps/<name>/Application.mk is still required though. A later release of the NDK will get rid of it too, but the change is too drastic for the upcoming release. The change moves various source files from sources into their app/<name>/project/jni directory as well. The whole documentation is updated to reflect the change.
104 lines
2.9 KiB
Plaintext
104 lines
2.9 KiB
Plaintext
Android NDK How-To:
|
|
===================
|
|
|
|
A collection of tips and tricks for NDK users
|
|
|
|
|
|
How to force the display of build commands:
|
|
-------------------------------------------
|
|
|
|
Do "make APP=<yourapp> V=1" and actual build commands will be
|
|
displayed. This can be used to verify that things are compiled
|
|
as you expect them to, and check for bugs in the NDK build system.
|
|
|
|
(The V=1 trick comes from the Linux kernel build system)
|
|
|
|
|
|
|
|
How to force a rebuild of all your sources:
|
|
-------------------------------------------
|
|
|
|
Use GNU Make's "-B" option, as in:
|
|
|
|
make APP=<yourapp> -B
|
|
|
|
|
|
How to store your native sources in a location other than $PROJECT/jni:
|
|
-----------------------------------------------------------------------
|
|
|
|
First, you can simply tell your $PROJECT/jni/Android.mk to include
|
|
another Android.mk that are located in different places.
|
|
|
|
Alternatively, you can define APP_BUILD_SCRIPT in your Application.mk
|
|
to point to an alternative Android.mk file, getting rid of the
|
|
$PROJECT/jni directory hierarchy entirely if you need to.
|
|
|
|
|
|
How to store your Application.mk in a location other than $NDK/app/<name>:
|
|
--------------------------------------------------------------------------
|
|
|
|
At the moment, the application descriptor files must be accessible from
|
|
$NDK/app/<name>. You can however create a symlink to a different directory.
|
|
|
|
For example, imagine that you wrote:
|
|
|
|
$PROJECT/jni/Application.mk
|
|
|
|
You can create a symlink like with a command like:
|
|
|
|
ln -s $PROJECT/jni $NDK/apps/<name>
|
|
|
|
This will make $NDK/apps/<name>/Application.mk point directly to
|
|
$PROJECT/jni/Application.mk
|
|
|
|
Note that generated files will still go under $NDK/out/apps/<name> though.
|
|
|
|
Windows users: The NDK is only supported on Cygwin, which implements
|
|
symbolic links through the "ln -s" command, as in:
|
|
|
|
ln -s <target> <link>
|
|
|
|
|
|
How to properly add include directories to your module declaration:
|
|
-------------------------------------------------------------------
|
|
|
|
If you define several modules, it is common to need to include one
|
|
module's header while compiling another one. For example, consider
|
|
the following example:
|
|
|
|
$NDK_ROOT/sources/foo/
|
|
Android.mk
|
|
foo.h
|
|
foo.c
|
|
|
|
$NDK_ROOT/sources/bar/
|
|
Android.mk
|
|
bar.c
|
|
|
|
Where the 'bar.c' uses '#include <foo.h>'. You will need to add the
|
|
path to the 'foo' module in bar/Android.mk to build it properly.
|
|
|
|
One is tempted to use the following:
|
|
|
|
LOCAL_C_INCLUDES := ../foo
|
|
|
|
However this will not work because all compilation happens from the
|
|
root NDK directory (i.e. $NDK_ROOT), and include files must be relative
|
|
to it. The above line really translates to:
|
|
|
|
LOCAL_C_INCLUDES := $(NDK_ROOT)/../foo
|
|
|
|
Which adds a non-existing directory to the C include path. The correct
|
|
line is instead:
|
|
|
|
LOCAL_C_INCLUDES := sources/foo
|
|
|
|
Or even better:
|
|
|
|
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo
|
|
|
|
Which uses a path relative to $(LOCAL_PATH), in the case where you would
|
|
need to move 'foo' and 'bar' to a deeper level in the 'sources' hierarchy.
|
|
|
|
|