GemRB on Playbook

[drosketer]

... wow... hah, I think that I may have, just slightly, underestimated the effort that this will entail. At that rate I might be dead before managing to get this baby to compile. Thanks for the hints on what lies ahead though.

 

If there is any way you can think of that I can help out in moving this forward, let me know. OOC, are you running the beta NDK, or 1.2? I wonder if there is going to be a lot of differences between them.

[scriptedfate]

Beta 2.0. The only difference for the NDKs for what we'll be using is against which simulator you're running and against what version of device you'd like to deploy. Since everyone's going to get the 2.0 update, I just went with 2.0.

 

There are a lot of differences in the 2.0 beta (like android runtime support if you still want to try out that route), just not many that matter to a program that just wants libc, SDL, and OpenAL.

 

As for underestimating effort... well, I did mention that I found a fix for the majority of the build errors? I'll be working on figuring out why that works and if I can switch the managed builder inside the IDE to the correct preprocessor conf, but in the meantime you can simply use it on the commandline. It might be as simple as setting CXX in CMakelists.txt to be qcc -V4.4.2,gcc_ntoarmlev7_gpp (for device build. replace armlev7 with x86 for simulator)

 

To get it to build needs some effort, we realize this. But we know how to solve the bigger problems now. What would be helpful is if you could pull down the old QNX Python port and see if you can get it building for PlayBook: http://sourceforge.net/projects/pyqnx/ That's the only required dependency I haven't worked out yet.

 

SDL for QNX is on github. Getting it to build is simply a matter of importing it as an NDK project and hitting 'build'.

 

And OpenAL and zlib we get for free with the platform.

 

We're actually pretty close, for a project that no one was working on a week ago.

[drosketer]

Will give it a try this weekend and report back...

[lynx]

btw, if multiple outputs is a problem, try making a static build (-DSTATIC_LINK=1).

[scriptedfate]

btw, if multiple outputs is a problem, try making a static build (-DSTATIC_LINK=1).

 

That still builds them all independently as '.a's, then statically links them into the binary, yes? Still problematic, since they each assume that they're being compiled in isolation 'first' before being linked in. Momentics' managed build seems to only support one build artefact per project. I could maybe stretch it a bit by specifying different flags for different folders and getting them to compile into libs that way... but that might be a bit much.

 

tomprince just suggested I turn off compilation for the plugins for which I don't have support (thank goodness for the nice folder structure!), and that looks like it might work. I need to fix a few more things (like Python) before I can tell for certain (though, of course, I can just nix those plugins as well. It won't leave me with a set of plugins that could play games, but maybe it'll give me a binary I can test).

 

Oh, and as an update on the compiler front, I now know why the _cpp/_gpp thingamy is the way it is. _cpp means using Dinkumware's C++ Standard Library, which is conformant. _gpp means using GNU libstdc++, which isn't.

 

To change between the two: In Momentics, change Project>Properties>C/C++ Build>Settings>Target>Runtime to "C++ GNU with exceptions". Apply, OK, rebuild.

 

Still inquiring about how to fix the Indexer/Scanner/Lookup to get rid of the red squigglies and allow global names to be recognized and looked up.

[SyntaxError]

no. STATIC_LINK does not build .a libs it compiles everything into the binary at compile time. i guess the name is misleading? its just a gemrb defined macro...