Hi Brent, Brent Gulanowski schrieb: > This is moved from the submissions forum/list. Forgive the mispost > there. > > Building the source from Xcode using the Xcode project file included > in the 2.8.1 distribution download, and encountered some issues. Not using cmake (which is unfamiliar to me). > > Notice that the Xcode build configurations are not using what are now > the standard names (Debug and Release), instead using the ones from a > few years back (Development and Deployment). Maybe a cosmetic thing, > but would be nice if they were standard.
Yeah, the xcode-project-files are really old. I don't see a standard in Deployment / Development. Other open source tools name them differently. In the end they are only used for folder-names. In the current trunk there are now 6 configurations 32bit Carbon debug / release, 32bit cocoa debug / release and 64bit cocoa debug/release. But feel free to modify the xcode-project and send them back to me, I'll test the changes on my end and submit them to subversion. > I find Xcode really dislikes the project. I don't know if it's my > system, or a bad index somewhere, but I have a horrendous problem > with Xcode constantly running both CPU cores hot whenever I do > anything in the OpenSceneGraph project. Anyone else have this > problem? I'm wondering if maybe the project has exceeded some limit > of Xcode's ability to handle either the number of files or the number > of targets in one project. As noted before, these files are hanging around for about 6 years. osg matured in that time a lot and not all movements were incorporated in the xcode-project-files. I like xcode a lot but it has some instabilities with big projects (like osg) and some annoyances (for example storing the full path to info.plist files in the project-configuration) which breaks interoperability for other users. > I've been unable to get it to build, nor can I successfully clean the > project, because it keeps claiming there is no build product name > defined for one of the aggregate targets (and trying to inspect the > same SDLdependentStuff target causes an exception). Can you describe your errors in more detail? Building the frameworks, plugins and examples should IMHO work. > I'm fairly novice with 3D but looking for a starting point that I can > use in Cocoa software for Mac OS X. Might even want something that > could work on iPhone eventually. I would definitely want to replace > the AGL with NSGL support, with which I am familiar. AFAIK you can't use dynamic libs on the iphone, you'll have to create static libs or add the source-files of the lib to your project. I think this is because of code-signing-issues. As Robert mentioned you'll need OpenGL ES 1.0 for the IPhone anyway which osg can't handle yet. As I am the "maintainer" of the xcode projects please send me your changes and I will check them in. It's really hard to maintain these project files, too many libs, plugins and examples to observe. For now I am using an automated build process to spot any compile errors on HEAD. But CMake is the future for building osg (you can use xcode for your own projects and add the osg-libs and plugins) If I find some spare-time in the near future I'll try to add framework-support to the cmake-files, because this is the only thing which stops me using cmake, and why I am still using+maintainting the xcode-projects. And, as Robert noted, the current trunk has now support for Cocoa + 64bit, and it's relatively easy to combine osgViewer with custom Cocoa-applications. But be aware, that this code needs some more love and is not fully tested. cheers, Stephan _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
