Raymond, In case it helps, my port is pretty much up to date, and it avoids cmake problems, dependencies and so on. It works with the latest XCode and it uses ObjectiveC Automatic Reference Counting. It's currently working with GLES1. I mentioned the github address on a previous e-mail on this thread.
Eduardo On Wed, May 2, 2012 at 12:11 PM, Raymond de Vries <[email protected]> wrote: > Hi Stephan, Thomas, > > I would like to follow your procedure to build a set of iOS libs and I am > following your instructions in this mail and on the new website (which is > progressing nicely btw, congrats!). I have some questions though... > > In this mail, you mention that cmake nightly build should be usable. In the > mean time 2.8.8 is out there so I guess that one should be usable, as also > mentioned on the osg iOS page. > > Now when I try to use cmake 2.8.8 by running 'cmake-gui .' from within the > osg svn folder, it doesn't find xcode. Do I need to configure xcode somehow > in order to find it? > > About your github mirror, I am not sure what the status is, or how I should > be able to use it. Browsing your mirror, the date of the files is not > up-to-date. Could you please explain it a bit more? > > Thanks a lot! > Raymond > > > > > On 4/21/12 11:40 AM, Stephan Huber wrote: >> >> Hi Wojciech, >> >> Am 20.04.12 17:28, schrieb Wojciech Lewandowski: >> >>> We want to port an OSG program to Ipad. This was once written on Windows. >>> We already gathered some experience on OSG/GLES when porting it to >>> Android. >>> And now its time for IOS. We are completely fresh on IOS Mac programming, >>> though. So fresh, we don't even own a Mac for development station, yet. >>> In >>> preparation for the task I was looking on OSG site and mailing list for >>> some guidance. My overall impression is not too rosy, though. I've found >>> posts that CMake does not work with XCode and XCode project has a >>> separate >>> manually maintained repo. Since I am a such a newbie on the topic I can't >>> figure out how severe the whole picture is and how easy or messy attempt >>> could be. So I decided to just start a small poll and ask these few >>> questions directly: >> >> CMake and XCode: >> >> XCode is now distributed via the mac app store, the app resides in the >> app-folder, and not as in previous versions in a dedicated folder called >> "/Developer" Older versions of Cmake required that xcode lives in >> /Developer. This broke project generation for xcode. Fortunately the >> nightly builds available at cmake.org include a bug fix, so cmake is >> working again for os x and ios. >> >> CMake generated project files vs hand-maintained xcode-project files on >> github (https://github.com/stmh/osg/tree/iphone >> >> >> cmake: >> + project files for most of the plugins >> - generated project files work either for the simulator or for the >> device (you'll need two xcode project files for sim and device) >> - no working example app >> >> hand-maintained xcode-project-files via github branch: >> + project can compile libs for device and lib >> + project can be embedded in other xcode-project and xcode can resolve >> all dependencies automatically. >> + working examples >> - only a handful plugins are supported >> >> >> >>> - Is IOS/OSG environment mature enough to attempt a more advanced >>> application than test samples ? >> >> I think it's stable enough to do serious work. AFAIK there are some apps >> in the wild from Thomas Hogarth and I published a small app two weeks ago. >> >>> - For larger app would you recommend XCode or command line Cmake build ? >> >> AFAIK It's necessary to use xcode for building an ipad app (codesigning >> for example), but you can compile your xcode project from the >> commandline using xcodebuild, which works good enough. I'd recommend >> xcode. >> >>> - I have read that XCode can be quite unresponsive with OSG project on >>> Mac >>> mini. Could you recommend some minimal HW configuration to handle the >>> environment and allow for comfortable work ? >> >> yes, that's true, xcode need a lot of cycles to open and munge the >> osg-project files, you can avoid this by compiling the osg libs and >> -plugins with xcodebuild via the command line; and, you'll do this only >> once to get a set of libs you can use for your further development tasks. >> >> So, basically you compile your osg libs and plugins once, set up your >> project and use the libs from there. Working on your own project with >> xcode is fast and flawless, so no worry about that. (linking will take >> its time though) >> >> A recent mac with plenty of RAM (xcode tends to use all available RAM it >> can get) and a lot of cores :) will suffice. I think an midsized >> quadcore iMac would be a good start. I do most of my development with a >> two year old MacBookPro with 8GB RAM and a 256GB SSD and on a four year >> old quad core Mac Pro. >> >>> - Can OSG/GLES program be tested on IPAD emulator on Mac ? We could not >>> do >>> it with Android (last week version of Android SDK supposedly changes >>> that) >>> ? >> >> If you compile osg for simulator and device, and adjust the project >> settings accordingly then you can test your app on the simulator and on >> the device. In my experience the simulator is slower than the actual >> device and you'll notice some artefacts/errors when rendering opengl es >> from within the simulator. >> >> I have a set of universal libs of osg which work for the device and for >> the simulator. If there's any interest I can share them online. (Built >> from the handmaintained xcode-project via github) >> >> The hard part with osg + ios is to get a set of working libs for >> simulator and device. If you have your libs and plugins in place >> development is as easy as with other platforms besides the longer >> compile-test/debug-on-device-cycles. >> >>> - OSG development on Android in my opinion is far from perfect situation >>> (comparing to Linux or Windows). If you had an experience with both >>> Android >>> and IOS can you just say if development for IPAD is simpler or tougher ? >> >> I don't have any experience with android, but when you have a set of osg >> libs ready for development, the experience is quite good. As xcode >> compiles your code while you are typing most of the common errors are >> spotted in realtime. The link times are really long, most notably for >> debug builds. >> >> Here's my personal setup: >> >> * I am using the handmaintained xcode-project files mostly because I do >> not need all the plugins >> * I have a dedicated old mini with continuous integration via hudson, >> which checks the iphone branch from github for changes and compiles all >> libs and plugins for simulator/device/debug/release. Via a shell script >> I combine the simulator and device libs to create so-called universal >> libs. If nothing went wrong headers, libs and plugins get committed to >> subversion automatically. >> * I am using xcode for my ios-apps, setting include-paths and header >> paths accordingly and that's it. >> * Most of the time i do release builds for testing, as linking the >> debug-targets takes a reasonable amount of time and are slow on the >> device and on the simulator. >> >> >> >> hope that helps. >> >> cheers, >> Stephan >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
