Hm... lets not kid ourselves. There are different layers of abstraction here and when I navigate "Frameworks" I see directory structures that include subdirectories named Resources and Headers. In some "Frameworks" I find files of type "Mach-O dynamically linked shared library (i386 or ppc)". However, for now, I'm going to assume that the XCode build system creates these and they aren't populated by your script. The script simply moves the entire .framework subdirectory from its build location to is place in the PackageDir.
Yes, there are different layers of abstraction, but my advice to you is 'keep out'. For your purposes, the framework should be treated as a black box/solid opaque object (as it is mostly intended to be treated). Coding to the internal substructure will most likely cause breakage at some point down the road. For example, if you look in our framework, there are no files with the .dylib extension. Yes, you will find a Mach-o dynamic library inside, but you're not going to see .dylib anywhere. Furthermore, if I or somebody else decides to implement build variants (debug, release, profile, etc), there will be multiple dynamic libraries inside the package. Or if we implement versioning, some of the directory names could be different and there will be multiple versions of dynamic libraries and multiple versions of headers. All of these features will break your 1-to-1 mapping on your table and will also break the framework if you don't preserve everything. So treat it as a single object.
So, what does the development environment directory structure (containing the target builds) look like just before your script is run which copies files to the distribution locations? -don
So currently, I track default Xcode 2.1+ behavior, where it dumps everything into a new directory Xcode makes called 'build/$(CONFIGURATION)' in the same directory as the Xcode projects, where I assume the Build configuration name is called "Deployment". However, this breaks down with Xcode features like shared build directories or if somebody renames or uses a different configuration name, so I've been considering moving the stand-alone shell script inside Xcode so I can reference variables like $CONFIGURATION (and other info that tells me where everything is) directly instead of assuming. (I just sent Sam some changes for SDL that do this :)) -Eric _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
