Android NDK - Force library rebuild on configuration change

Question

Is there a way to force the Android NDK to rebuild a particular library when changing build configurations in Eclipse?

I am building building an Android Project using the Android NDK to build C++ libraries. I am using Eclipse with the Sequoyah plugin. Everything is set up and works well.

However, I have run into an issue with build configurations. You can manage build configurations by right-clicking the project->properties and then go to the C/C++ Build section. This allows you to create the traditional Debug, and Release builds that most C++ libraries depend on in some way.

Here is an example of my "Debug" configuration:

V=1 NDK_DEBUG=1 NDK_APPLICATION_MK=config/debug/Application.mk

These work well, except that when I switch back and forth between configurations, it does not trigger a rebuild of the libraries I am building. This would be expected for something like Visual Studio where each build config dumps to a different directory, but in Eclipse everything gets dumped to the same directory. I am forced to actually change relevant source files to trigger a rebuild. So what ends up happening is I end up running (for instance) in the Debug configuration but linking to libraries that were built in Release.

So my question is: is there a way to force the NDK to rebuild a library when changing configurations? I am aware of the -B command I can add, but that rebuilds everything, everytime. I would be OK rebuilding every time, if I could do it for just one specific library (in this case libBootInfo).

Here is what my root Android.mk file looks like:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := game$(MY_BUILD_CONFIG_EXTENSION)

# Include files are relative to the NDK root directly (fix by prepending with $(LOCAL_PATH))
# Source files are relative $(LOCAL_PATH)

#LOCAL_LDLIBS    := -landroid

# Add all source file names to be included in lib separated by a whitespace
LOCAL_SRC_FILES :=  ../../../../../../engine/code/main/mainandroid.cpp

# Module dependencies are expressed with LOCAL_STATIC_LIBRARIES and LOCAL_SHARED_LIBRARIES.
# we're building the "main" entry point, so it doesn't depend on much
LOCAL_STATIC_LIBRARIES := libDebug$(MY_BUILD_CONFIG_EXTENSION) libCore$(MY_BUILD_CONFIG_EXTENSION)

include $(BUILD_SHARED_LIBRARY)

$(call import-module,libBdCore)
$(call import-module,libDebug)

##################################################################
## In addition to the core game library, we also build another
## *.so file here: "libBootInfo". This very small library is used
## by Java to find out which version of game to load based on
## the current build configuration.
##

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := libBootInfo

# Add all source file names to be included in lib separated by a whitespace
# TODO: This path is relative to "android-ndk\build\core" which seems
#       different from the LOCAL_SRC_FILES in game above. It seems like
#       the build process leaves us in a different directory than we started.
#       We make need to look into a way to make sure that this path always 
#       works regardless of what came before it.
#
LOCAL_SRC_FILES := ../../../../engine/code/main/bootinfo.cpp

include $(BUILD_SHARED_LIBRARY)

Answer 1

I was never able to get this working quite right. In the end I just created a batch file which wrote out an empty source file. That batch file is executed as part of a build step in Eclipse. I then included that source file as part of my library. Since the time stamp changes every time I build, it tricks ndk into rebuilding that library every time. I make sure that library is kept small and most code lives in other libraries, making the build time quite short.

Answer 2

NDK build always refreshes the .so libraries in lib/armeabi. The obj directory, on the other hand, contains separate trees for debug and release builds, for each module.

Unfortunately, it's rather easy to screw this setup if your Android.mk does something not supported by tge framework.

For example, in your case, the long upgoing paths to cpp files (../../../..) may be a bad idea. I would advise to set LOCAL_PATH for each module, and avoid ../ in LOCAL_SRC_FILES.

Here is my suggested change for Android.mk:

ANDROID_MK_PATH := $(call my-dir)
LOCAL_PATH := $(ANDROID_MK_PATH)/../../../engine/code/main

include $(CLEAR_VARS)

LOCAL_MODULE := game$(MY_BUILD_CONFIG_EXTENSION)
LOCAL_SRC_FILES :=  mainandroid.cpp
LOCAL_STATIC_LIBRARIES := libDebug$(MY_BUILD_CONFIG_EXTENSION) libCore$(MY_BUILD_CONFIG_EXTENSION)

include $(BUILD_SHARED_LIBRARY)

##################################################################
## In addition to the core game library, we also build another
## *.so file here: "libBootInfo". This very small library is used
## by Java to find out which version of game to load based on
## the current build configuration.
##

include $(CLEAR_VARS)

LOCAL_MODULE := libBootInfo
LOCAL_SRC_FILES := bootinfo.cpp

include $(BUILD_SHARED_LIBRARY)

$(call import-module,libBdCore)
$(call import-module,libDebug)

UPDATE: Actually, using a module name suffix to separate the build configurations is, in my eyes, the best solution. This approach allows you to build and deploy more than one configuration at a time. For example, I use it when I have to optimize a library either to Tegra (without Neon) or to Snapdragon (with Neon): until recently, it was not easy to place two separate APKs on the Play Store, therefore I was packaging both libv-neon.so and libv-tegra.so into lib/armeabi-v7a.

I don't know what logic your BootInfo library includes, but if you are only deploying one library, you can avoid all the hassle with the following code in your Java class static constructor:

static {
    boolean loaded = false;
    while (!loaded) {
        try {
            System.loadLibrary("game" + nextExtensionAttempt);
            loaded = true;
        } 
        catch (Exception ex) {
        }
    }
}

An alternative approach would be to override the output directory ./obj. For this purpose, you can add the following line to your Application.mk file:

NDK_APP_OUT := obj$(MY_BUILD_EXTENSION)

this way all the .obj, .a, and .so files (before they are installed into libs/armeabi) will be placed in a separate directory per configuration. Even easier, you can supply NDK_OUT parameter on the ndk-build command line, e.g.

ndk-build V=1 NDK_OUT=obj${MY_BUILD_EXTENSION}

This is very easy if you use Eclipse to maintain and choose your configurations. This makes it easy for Java to load the module, because it will always have the same name. But you can only deploy single configuration at a time.