Re: What's the best solution to the old framework in a framework problem?
Re: What's the best solution to the old framework in a framework problem?
- Subject: Re: What's the best solution to the old framework in a framework problem?
- From: Marcel Weiher <email@hidden>
- Date: Sat, 27 Mar 2004 14:34:50 +0000
I think it's a bug in the current dyld, since the whole
@executable_path/../Frameworks/ thing is a hack, AFAICT.
I currently use (5), and it is workable but tiresome. Writing a loader
shouldn't be that awful, at least with soft-linking available after
10.2 (?). At least I've been able to load frameworks just like bundles
using NSBundle. However, it does seem to be significantly slower than
plain linking, on the order of several seconds instead of fractions of
a second.
Another option I've meant to explore is changing the 'install' location
of subsidiary frameworks during the install/build to point to
@executabe_path/../Frameworks/MyUmbrellaFramework.framework/Frameworks/
.
Marcel
On 27 Mar 2004, at 13:06, John Clayton wrote:
Oh, and ,
5) Have users of the framework separately include each required
framework in their projects.
Anybody?
On Mar 24, 2004, at 11:11 PM, John Clayton wrote:
I know there have been many discussions of this subject on the list,
with varying responses. I'm wondering how people are actually
solving this issue.
The basic problem is that including a framework or other dynamically
loaded library in a framework doesn't work because the application
including the parent framework can't load the subframework because
it's not in the library paths. Building the subframework with the
@executable_path/../Frameworks doesn't work because relative to the
app, it's not in that path. From what I can glean, the options are:
1) Build an umbrella framework that is stationary (in one of the
default library paths) and stick the subframeworks under there.
Drawbacks are that this defeats the drag-and-drop installation
experience and that Apple recommends nobody but them do this.
2) Roll your own loader. Some people have talked about this, but it
seems difficult at best (examples would be appreciated) and I wonder
about performance issues here.
3) Build the subframeworks as static libraries and include those in
the parent framework. This has the disadvantage of losing the lazy
loading of needed resources. Plus, one might not have the source
code ;-(
4) Incorporate all the code into a single framework. Same issues as
above, I guess.
None of these options seems too great.
I wonder, is it considered a bug in dyld that this situation isn't
workable, or is it by design? In any case, I'd really appreciate
your wisdom on this subject. Thanks a lot,
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
1d480c25f397c4786386135f8e8938e4
_______________________________________________
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.