Module dependences error?

cocos2d-x C++
1

Dear all,
I’m not sure if this is a cocos2d-x issue (it might be Android NDK-related) but it can be useful to discuss it here in case someone else faces it. I’m using NDK-r5 and cocos2d-x 0.7.2.

So cocos2d-x comes with two tests project, “helloworld” and “test”. This tests are based on additional modules (shared libraries) that are build along with the test project by issuing the ndk-build command. These libraries are Box2D, cocos2d and cocosdenshion.

So far so good. I started my project called “siege” and I was able to do the same - that is, use those shared libraries in my project (building them alongside my project).

Problems rised when I added another external module (shared library), “tinyXML”. I set up tinyXML as it has been done with Box2D, that is I put it in an external folder and I copied the Android.mk from Box2D, then modified it to my needs (i.e. replace name of source file and module name).

Now my project won’t build because no matter what I set in my project’s Android.mk, it builds box2d, cocos2d, cocosdenshion, my project (“siege”) and then tinyXML. The order is important! It fails while building my project because tinyXML is not built yet.

I tried using various definition in my project Android.mk, including (I list all the alternatives I tried):

LOCAL_SHARED_LIBRARIES += tinyXML
LOCAL_ADDITIONAL_DEPENDENCIES += libtinyxml

LOCAL_REQUIRED_MODULES += libtinyxml

LOCAL_SHARED_LIBRARIES := tinyXML (and so on, using := instead of +=)
LOCAL_SHARED_LIBRARIES := libtinyxml (and so on, using libtinyxml instead of tinyxml)

none of this seems to fix the build order. It seems to me that the build is performed in alphabetical order. Box2d, cocos2d, cocosdenshion, siege, tinyxml, no matter what you specify as dependences.

To investigate this, I renamed tinyxml to aaatinyxml and it’s building like a charm, as it’s build first. Anyone experiencing the same problem? Am I missing some definitions that specify the order of the build?

I believe the test projects shipped with cocos2d-x might be liable to the same problem - it might be a coincidence that Helloworld and Test (H and T) come after B and C so the build order is correct. What happen if you change HelloWorld to aaaHelloWorld? (I’m too la…. busy to try myself :))

2

It’s so funny. I haven’t notice the alphabetical order. So we’re lucky to name “HelloWorld” & “Tests”.
This maybe a trick in somewhere of android bulid-rule.

3

I do not think so. What is your Android.mk that in folder jni look like?

4

Following cocos2d-x “Test” sample, I have this Android.mk in the jni folder:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
MY_SIEGE_PATH := $(LOCAL_PATH)
MY_LIBS :=  $(LOCAL_PATH)/../../Box2D/Android.mk \
            $(LOCAL_PATH)/../../cocos2dx/Android.mk \
            $(LOCAL_PATH)/../../CocosDenshion/android/Android.mk \
            $(LOCAL_PATH)/../../tinyxml/Android.mk \

include $(MY_LIBS)
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
include $(MY_SIEGE_PATH)/siege/Android.mk

and in the jni/siege folder, this Android.mk

LOCAL_PATH := $(call my-dir)


include $(CLEAR_VARS)


LOCAL_MODULE := siege


PROJECT_PATH := $(LOCAL_PATH)/../../../


LOCAL_SRC_FILES :=  siege.cpp \

                    AppDelegate.cpp \

                    scenes/menuLayer.cpp \

                    scenes/playLayer.cpp \

                    scenes/playScene.cpp \

                    scenes/levelSelectionScene.cpp \

                    scenes/levelLayer.cpp \

                    core/WorldLevels.cpp





LOCAL_C_INCLUDES := $(PROJECT_PATH)/cocos2dx \

                   $(PROJECT_PATH)/cocos2dx/include \

                   $(PROJECT_PATH)/CocosDenshion/include \

                   $(PROJECT_PATH)/tinyxml \

                   $(PROJECT_PATH)/Box2D \

                   $(LOCAL_PATH)/jni/siege



LOCAL_LDLIBS := -L$(LOCAL_PATH)/../../libs/armeabi \

                -lGLESv1_CM \

                -lcocos2d -lcocosdenshion -llog \

                -lbox2d \

                -laaatinyxml



include $(BUILD_SHARED_LIBRARY)