Android tests

[tigerw]

I've a question about Android builds.

As you can see from the android branch, there's been an attempt to set up non-interactive builds with CMake to integrate nicely with the rest of the project. However, I'm encountering difficulty linking an Android library (Java <-> C++ interface code) with the other libraries (OSSupport, Blocks, etc.) into a single shared library containing all symbols.

I have a CMakeLists.txt in the Android folder, doing

Code:

add_library(AndroidNative jni/app-android.cpp jni/ToJava.cpp jni/ToJava.h)
target_link_libraries(AndroidNative log dl)

where the jni folder contains the interface code and 'log dl' are some additional dependencies (android logging framework and such).

I also have changed, in the src folder, the CMakeList to do

Code:

add_library(MCServer SHARED ${src cpp files variable})
...
target_link_libraries(OSSupport Blocks BlockEntities ...etc...)
if (ANDROID)
    target_link_libraries(AndroidNative atomic)
endif()

where AndroidNative was the previous created library and 'atomic' is a dependency.

However, it doesn't work. Examination of the final .so file using Cygwin and the Linux nm program tells me none of the definitions in the jni folder got through, and consequently the Java VM crashes since it can't find them. Yet, if I add the cpp files directly to, say, the SRCS and HDRS variable in an already existing library, say, Main (for the root src folder), it works, and all the symbols are added (verified by nm and successful APK execution).

Please see the android branch if I am being unclear. I also attach some positive news, built with commandline only.

Question: I suppose I am trying to link the AndroidNative library wrongly, or am missing a step. Halp pl0x?

[worktycho]

What are the actual error messages? Does it fail at runtime or compile time?

[tigerw]

Everything links fine. Java can fond the resulting library. It fails at runtime though, with a message similar to 'can't find function definition Java_org_mcserver_MCServerActivity_NativeIsServerRunning'.

[worktycho]

I suggest using the nm and readelf files to look at the object file to see exactly where the difference is between the two build methods.

[tigerw]

Well hello old me. Everything is working now (yay~), except for the part where bindings are generated by tolua.

Does anyone have any idea about how the Linux build system generates its bindings and how that might work when crosscompiling on Windows?

[worktycho]

I think you need to point cmake at a windows version of tolua. http://www.cmake.org/Wiki/CMake_Cross_Co..._the_build is the relevant docs. I'll probably have some time this weekend because of the bank holiday, so I can have a look then if you want.

[tigerw]

Please do take a look, thanks for the offer!

The link suggests that a native binary must be compiled first before the crosscompile begins. Do you think http://www.kitware.com/media/html/Buildi...ke2.8.html could automate that step?

Another question:
Say I get a Windows tolua built, where should the executable go for the custom generation command to find it? At the present moment, the binding generation command doesn't even attempt to run. Since I cleaned everything out, when a file attempts to #include "Bindings.cpp", it doesn't exist, isn't generated, and the build fails.

[worktycho]

I think the automation should go outside the cmakelist, because you need to rebuild the build script after running it. As for the location, the ImportedExecutables.cmake file should handle it.

[xoft]

How about changing the build so that it uses system lua, if available, to execute the ToLua parser? Then crosscompiling would simply make it a necessity to have system-lua available, while normal builds could still use the compiled exe.

[worktycho]

Possibly, but it might cause problems if cmake tries to use an arm system lua. Personally I suspect the best option is the double build, as it is how cmake is supposed to work.