On 10/2/06 12:28 AM, "Don Burns" <[EMAIL PROTECTED]> wrote:

> 
> 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?

It can be different for each user because it is a setting that can be
changed. For instance, I have everything that Xcode Builds put into a
central directory in my home folder called "XcodeBuild" ( ~/XcodeBuild).
Within this directory there will be a directory for the "type" of build that
was performed (Debug, Release, Deployment, Development). Inside one of those
directories you would find the *.framework folders, the plugins and all the
.app packages that were built by Xcode. Eric's scripts are taking those
built items from that "XcodeBuild/Release/" directory, arranging them in
another temp directory then creating the DMG from that temp directory.
  Eric's scripts probably assumes a default Xcode installation and no one
messing with build locations. If this is the case then there should be a
"Build" folder inside each project (OSG, OT, OP) where each of the
*.frameworks, plugins and apps can be located.

OS X's preferred system for libraries is to package them into the
"Framework" directory structure so that all the libs, includes, binaries,
and other resources (images, help files, etc) can be stored. These
frameworks are typically stored in one of several locations:
 /System/Library/Frameworks  <--- Apple's stuff here
/Library/Frameworks   <--- 3rd party here for all users
~/Library/Frameworks  <-- Per user frameworks.

OS will search these paths to look for frameworks automatically.

With all that having been said, IF someone wanted to treat OS X as just
another UNIX then there certainly is NO problem building all the OSG stuff
as .dylibs and sticking them done in /usr/local/lib and the includes down in
/usr/local/include. The make files just need to work correctly to take into
account any idiosyncrasies of OS X.

One last item, OS X stores the path to the Library in the actual library
header. This is so that other libraries that link against the first library
know where to find the library at runtime. This makes it so that things like
"LD_LIBRARY_PATH" do not have to be set. Eric uses a "special" path for the
OSG libraries that looks like "@executable_path/../Frameworks". This allows
the frameworks to be embedded in the .app package which then allows for a
single drag and drop application installation. If you use the Makefile
system to build the OSG packages a decision needs to be made if you are
going to encode the installation path into the libraries or rely on the
user/developer to set up his/her paths correctly.

I know this is a lot to take in but please keep asking the questions and we
will do our best to answer them.

I think in the short term if you are worried about something happening to
Eric's ability to produce an installation package for OSG then it would be
prudent to keep the Makefiles updated and working on OS X in addition to all
the other systems that you have. That way if something happens and an OS X
specific installation is not possible, there is always the Makefile system.

Hope all this helps.
-- 
Mike Jackson   Senior Research Engineer
Innovative Management & Technology Services




_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to