Crosscompiling cuberite with the NDK

[ghost]

src/LeakFinder.cpp:100:19: fatal error: tchar.h: No such file or directory
 #include <tchar.h>
                   ^
compilation terminated.

I am compiling on linux for android, but this header appears to be a windows one.

why are you forcing to use this? should LeakFinder.cpp be only available on windows?

the same goes for StackWalker.cpp (line 79)

---

For NetworkSingleton.cpp i receive similar errors. It includes event2/event-config.h, which isnt bad, but while looking for this file, i found out it is under this path. lib/libevent/WIN32-Code/nmake/event2/event-config.h

Shall I include that, or what shall i do?

---

This error src/OSSupport/NetworkSingleton.cpp:74:4: error: #error No threading implemented for EVTHREAD is thrown by the preprocessor. Why? and how can i resolve this?

[worktycho]

LeakFinder is only used on windows builds. Its a development tool to get around the lack of valgrind on linux and completely unnecessary. How are you crosscompiling?

[ghost]

Thanks for pointing out that i can just omit LeakFinder.

I am compiling through the NDK, with its own build scripts

if you are interested: http://developer.android.com/ndk/guides/android_mk.html

[worktycho]

Thats probably the problem. Cubrite has a non trivial build process. For libevent, the problem is that the CMakeList should generate the config file form event-config.h.cmake in lib/libevent. SInce you aren't running cmake, this isn't happening. Because libevent isn't configured, you then get the error in NetworkSingleton about no threading configuration.

Also, you'll need to run tolua to generate the bindings, and generate BuildInfo.h

[ghost]

ok. so if we break it down to which cmake commands must be run just for configuration? i mean without compiling anything (i can tell the ndk to run a shell command, but that wouldnt make it cross-compile)

[worktycho]

Not really. Tolua is run as part of the generated project file, so you have to at least build the bindings and all its dependencies to generate bindings. You're better off trying to get cmake to understand the NDK toolchain.

[worktycho]

http://developer.android.com/ndk/guides/standalone_toolchain.html

[tigerw]

I've done all of this in #2526, except that I haven't had time to address tycho's comments. sigh

[ghost]

I tried that before and it didn't work properly.

And I am not very experienced in cmake @tigerw so it would be cool if you do that again (and include in your pr the deletion of the Android directory, it's obsolete with my app)

Note: I only need binaries, no whole apk, and if possible the binaries for every abi (so we could write a Jenkins script to provide the binaries directly). If possible, build everything statically linked.

[worktycho]

@tigerw Are you still working on #2526, because it looks like some of the issues (atomics) have been fixed in newer NDK releases.

[ghost]

#3064

I think we can close this and my current work in favor of #2526

As long as we don't have working binaries for every abi I won't start with the app again, because I cannot test my code. I am sorry

[tigerw]

@tigerw Are you still working on #2526, because it looks like some of the issues (atomics) have been fixed in newer NDK releases.

I will have a look, sometime.