Re: "First Run" installation of Application support stuff?
Re: "First Run" installation of Application support stuff?
- Subject: Re: "First Run" installation of Application support stuff?
- From: Mike Ferris <email@hidden>
- Date: Fri, 20 Dec 2002 09:33:28 -0800
It's OK for us to discuss where apps can find their prefs, utility
files
etc, what about custom frameworks? I have several apps which share a
number
of frameworks (and which therefore cannot reside inside an individual
.app's
bundle). The way the link- and run-time systems operate, these
frameworks
need to be stored in either a hard-coded location or a well-known
location.
How does that square with drag-from-CD installation and drag-to-trash
uninstallation?
Or does someone have a link-time trick which allows dyld to find
frameworks
using relative paths, such as in a sub-directory of the directory
containing
the .app?
Or maybe even a trick to allow an app whose frameworks cannot be found
by
dyld to get a chance to locate the frameworks itself and reconfigure
its
link information...
This is an area where Apple mechanism and policy is still kind of in
the hand-waving stage.
The one thing you can do currently is a pain and requires various
trickery in certain circumstances but...
The limitation is that you have to be able to require/control the
layout of the apps and frameworks with respect to each other. Here's
one simple layout that will work:
My Application Suite/
My Application 1.app
My Application 2.app
My Application 3.app
My Application 4.app
Support
Frameworks
My Shared Framework 1.framework
My Shared Framework 2.framework
The real requirement is that all executables that link the framework(s)
be able to find the frameworks via the same relative path starting at
the executable.
What you do is use the @executable_path linker support (the same thing
you use to embed a framework inside an app wrapper.) But you provide
more ".."'s than you would in the embedding case. In the above
example, the -install_name flag to the linker for the first framework
would be "@executable_path/../../../Support/Frameworks/My Shared
Framework 1.framework/Versions/A/My Shared Framework 1" (which means
the "Install Location" setting in PB would be
"@executable_path/../../../Support/Frameworks".) (And note that the
December tools provide a new way to control the -install_name argument
separate from Install Location, so you might consider using that
instead so the framework targets can still install themselves in a real
location...)
You'll have to get trickier about things if, for example, you have both
apps and command-line tools that link these frameworks since usually
the apps and command-line tools would not naturally be in locations
that would lend themselves to using the same relative path to locate
frameworks... but if all else fails, symlinks can be your friend here.
It is possible that Apple could someday provide much better solutions
to both this problem and the embedded framework problem, but for now we
must make do with what's there.
Mike
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.