So OS X is quite different. The reason it is different is because Apple has made serious efforts to avoid the need of "installation" and installers. The ultimate goal (particularly with end-users) is that applications can be placed anywhere on the computer (or mounted disk (image)) and it will still run.
OS X is also different in that you can do things the traditional Unix way, or do things the NeXT/Apple way. In the traditional Unix way, what you have documented will be very similar if not identical. But it fails to distinguish between end-users and developers, where end-users should have something stupidly easy to use and not require escalated permissions to dump files all over the file system (not to mention what if the user wants to remove your program). So looking at the NeXT/Apple way, this is what you want to do.
From an end-user Application stand-point, nothing gets "installed".
Everything is "bundled" within the application. Apple documents their bundle here: http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/Concepts/BundleAnatomy.html But the basic idea is that you have a special file and directory structure that OS X knows how to look at. To end-users, Apple makes this structure look like a single file. But the directory structure contains everything you need to run, the executables, the libraries, the resources (models, images, etc), the icon, and the plugins. This also has the advantage that it avoids 'dll hell'. We document this in the OSX/OSG readme file. Also, if you look at the binary package for OSX/OSG, and you go into the Examples folder, you can just double-click on the applications (that don't require arguments; try osganimate) and they just run without "installing" them or copying them out of the mounted disk image. (I cheat a little to save disk space and use symbolic links to create the bundle structure for every app, but it demonstrates the principle.) I really encourage you to use your new iMac to try this stuff out. So most "good" OS X applications never have an "installer". Everything is drag and drop. (Apple ironically, is the worst offender of this guideline. Adobe is also a horrible offender and they are worse because they don't even use the built-in system installer. And somewhat ironically, Microsoft Office for OS X can actually be drag-and-dropped instead of going through their installer.) Now for developers, we do have a few install locations to make life easier for them. These follow built-in OS rules and conventions. Frameworks are to be installed in /Library/Frameworks. The system is hardwired to look for user frameworks there. You can also install to ~/Library/Frameworks on a per-user basis. This is documented by Apple, but I think you must add this directory to your search path. PlugIns don't have a hardcoded location, but there are conventions written in the Apple HI guidelines, the first of which is to look in the Application bundle. For developer convenience, we added code in OSG to look in /Library/Application Support/OpenSceneGraph/PlugIns and ~/Library/Application Support/OpenSceneGraph/PlugIns. In principle though, any plugins that can't be added to the bundle for some reason, should be added to your application's specific Application Support/<your-app>/PlugIns. This also needs to be setup explicitly with osgDB by registering this new path. Debug vs Release frameworks is something that is still sort of a sore issue. Apple actually has a really slick way of creating a framework that contains release, debug, and profile variants of a framework. Then at runtime, you can set an environmental variable that pulls in the debug or profile variants. (You can also rename some files in the framework.) But this is something I haven't had time to pursue yet and Apple doesn't talk about this feature much so I'm wondering if that means anything. (Another slick feature is Framework Multi-Versioning, but I've gotten some rather explicit feedback from Apple folks that I probably shouldn't do this.) Also, the DWARF debug format has the ability to produce stand-alone .dSYM files. I thought I heard this could be exploited to solve the debug/release problem. A third solution is to reference the OSG Xcode project directly in your own Xcode project. Xcode has per-configuration build directories it knows how to traverse. In theory, you could set this up yourself by using the -F switch and do what ever you want. But this falls completely outside of OSG trying to dictate policy and is up to Xcode or user conventions. Right now, I do the painful thing of copying over or changing symlinks around in my /Library/Frameworks directory. Documentation is also somewhat of a pain. There is no "user" area explicitly defined for documentation unfortunately. You can dump documentation with the Apple documentation, but Apple pretty much says 'keep out'. (They have the right to do a complete uninstall and new install on Xcode update which means you lose your files in those directories.) If you have man pages, you can hook into the man services. Otherwise, it's up to the user to figure out where to put it and where to find it when they need it. (/Library/Application Support/OpenSceneGraph/Documentation might be a good place). Anyway, a lot of this is documented in the OSG/OSX Readme. I really encourage you to look at that and try at our binary package since you have access to a Mac. -Eric _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
