Android makefile

[mrwonko]

The code compiles nicely with the Android NDK using gcc 4.8 (though I have a lot of coding to do until I'm able to actually run anything, so I can't comment on that yet). This is the Android makefile I used, cleaned up a bit for easier use.

I guess this might be useful for others so maybe it should be included? A custom Android makefile for Lua is also required, where could that go?

Willi (from the mailing list)

[decimad]

Hi Willi! I never did anything with android, isn't CMake able to create the necessary Android makefiles? I'm just guessing here...

[decimad]

Hrmmm, apparently the bare cmake isn't able to. I found https://gitorious.org/android-cmake though, maybe that's worth a try? Sounds like it was designed to make android-toolchain makefiles from cmake-script files. I'm hesitating to introduce a duplication (I will most certainly forget to update the android makefile somewhen) before I know there is no better solution!

[mrwonko]

I'm hesitating to introduce a duplication (I will most certainly forget to update the android makefile somewhen) before I know there is no better solution!

Yeah, I can understand that. I'm a fan of cmake myself. Part of the reason for this pull request was just to report that it compiles.

A better solution might be introducing android support for cmake. I currently have enough on my hands though, not going to try that.

[decimad]

Same here, I'm spending irrationally too much time on luabind currently ;) I looked through what assembler MSVC emits and found that it would be worthwile to get rid of tag arguments internally... so my next focus will be to avoid them internally, that should also help with binary size.

[mrwonko]

I've got it running now. Well, it's not really running since luabind::open(state) causes a SIGSEGV without any stacktrace. The latter is presumably my fault in some way or another, I don't know about the Segmentation Fault though... I'll stick to the Lua C API for now.

[decimad]

Hey there! Well I can only guess what might be wrong. The lua_State* you pass to luabind::open could possibly not be a valid lua_State? luabind::open does not create a lua state, it only registers some basic internal tables with an already existing lua state. I'm sorry if I'm targetting to "low", it's just that I don't have much contextual information. Of course I'm interested in what could be the cause for this problem.

[mrwonko]

It was created using luaL_newstate() and the result was not NULL, so it should be a valid state. And even if it wasn't, the result shouldn't be a Segmentation Fault. If I had a stack trace I'd investigate further, as it stands I don't currently have the time. I'll put it on my todo list and try to investigate later.

[decimad]

Hi, Ryan commited just yesterday with a change to his set_package_preload functionality, which seems to have caused segfaults. As I forked from him, I figure maybe that's what is causing the segfaults on your side. Can I ask you for the favor of trying that? Also note, I've commited another few changes, the next bunch of changes will only affect users of lua-side classes.

[tripleslash]

Oberon's branch implements a better set_package_preload function. Maybe you can adopt this and some other major fixes?

[decimad]

Everything in due time ;) I'm currently preparing a preview branch so you can see what I'm up to with regard to object_rep's, smart-ptrs and the like. That would set us up in the same spot so we could even join forces, if you like ;) It's always better for a library to be worked on by multiple parties with different interrests, because one may only have so many use cases...

[tripleslash]

anything new yet?

[decimad]

Closed for inactivity.