I think I undestand this, actually. I did spend some time learning how to make bundles and frameworks, etc. But... alas, I've forgotten.
Please read the page I put up. You will see that I'm not actually looking to install things on Mac OSX in a "standard" location. What I'm really looking for here is where to put the components of the software build system into the distribution. Framework or no, you still have to move files from the build system into a distributable package, and I happen to know that the Mac OSX Frame work has "standard" locations within the framework to place things. Its just that you can grab that root and hang it anywhere on the file system you so choose.
This doesn't actually differ that much from what I am proposing for Windows, but in this case, we define the directory structure under $(ROOT). I've suggested that $(ROOT) be at C:\Program Files, but it could also move anywhere.
So, the question is, where does osg/Node go (under $(FRAMEWORK))? where does osg.dylib go (under $(FRAMEWORK))? where does osgviewer go (under $(FRAMEWORK))? etc.
Perhaps the XCode system already does all this for you. If so, that's great.
-don
On 9/28/06, E. Wing <[EMAIL PROTECTED]> wrote:
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/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
