Re: SharedFrameworks
Re: SharedFrameworks
- Subject: Re: SharedFrameworks
- From: Ryan Britton <email@hidden>
- Date: Thu, 13 Oct 2005 07:50:04 -0700
You can load a framework with a bundle, but it takes an extra step.
I have the following in my build process for using the DotMacKit
framework inside a loadable bundle.
/usr/bin/install_name_tool -change @executable_path/../Frameworks/
DotMacKit.framework/Versions/A/DotMacKit @loader_path/../Frameworks/
DotMacKit.framework/Versions/A/DotMacKit ${TARGET_BUILD_DIR}/$
{PRODUCT_NAME}.destModule/Contents/MacOS/${PRODUCT_NAME}
This makes it look for the framework relative to the loader (the
bundle) rather than the executable (whatever probably loaded the
bundle). You can run otool -L on the actual binary file to get the
appropriate path for the command.
On Oct 13, 2005, at 7:12 AM, Lawrence Sanbourne wrote:
On 10/12/05, Sherm Pendley <email@hidden> wrote:
On Oct 12, 2005, at 2:43 PM, Lawrence Sanbourne wrote:
What is the SharedFrameworks directory in a bundle for? I can't find
any useful documentation on it.
If I remember correctly, I think it's added to the framework search
path along with ~/Library/Frameworks, etc. So, when the dynamic
linker looks for a framework that has an install name that doesn't
specify a path, it'll look in SharedFrameworks/ for the framework,
but if a newer version of the framework is found elsewhere it will
use that instead.
I think it's poorly documented and not often used because it makes
testing difficult - Your app might wind up using a framework version
that hadn't been released yet when your app was written, and if the
newer framework version isn't compatible with your app, you're
screwed. Using SharedFrameworks/ is basically asking for the Mac
version of "DLL Hell".
SharedFrameworks/ sounds like what I need, but I agree with your
criticisms of it.
What would you suggest instead so that several applications in a suite
can share code without duplicating it among them? I wanted to include
the .framework in Resources and install it at runtime if necessary,
but you can't load a framework using NSBundle.
Would it make sense to use a loadable bundle (plug-in) for this? The
main app in the suite would store the plug-in in Resources/ and then
it and the other apps could find it and load it. (This would use
LaunchServices to locate the app bundle and then dig into the
Resources/ folder.) Then this wouldn't require clumsy .pkgs, and the
suite's resources would be completely self-contained. Is there a
better approach?
Thanks very much,
Larry
--
Larry Sanbourne
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden