I have a large (-ish) GLES2 game implemented for Nokia Harmattan platform on C++. I would like to port it to iphone. (For the record, it does not depend on any major middleware component but implements its own rendering loop, touch handling, timers etc.)
My idea is to compile the C++ as a static library and use GLKView and GLKViewController to implement a thin objective-C wrapper containing the main loop and basically hook all C++ functionality under update and draw calls (and of course route touch events to the appropriate methods in my codebase).
The question is: How to lay out the project for iphone so that developing it further is least painful? I can see three options:
1) Work solely on command line with makefiles etc. (However, is it possible to do everything on command line, including deploying to iphone?)
2) Use makefiles and such to build all C++ code as a static library outside Xcode and introduce it to Xcode as a makefile or lib.a file and have the objective-C wrapper in Xcode.
3) Put everything under Xcode. (How easy it is to maintain the wrapper and the C++ library as separate components under the same project? Is there a lot of initial work to move the C++ code under Xcode build system?)
I’ve done similar things and ended up with multiple linked Xcode projects. For a beginner, that’s (arguably) easiest. You can have multiple targets in one Xcode project but that’s a bit more advanced and may not fit your modularization anyway. You can easily have one project for the library and one project for that app (and Xcode will build them all with one keystroke.)
I didn’t think trying to duplicate all the stuff that Xcode does with Makefiles really feasible. There’s too much framework/multiple arch stuff in there. And you pretty much have to use Xcode to get things on the device anyway.