Jens,
Thank you for confirming my suspicions. I know that Bundle won’t help. What I
was hoping for was a Swift runtime call that returned the current module name.
Since (at least by convention), there is a correspondence between module names
and framework names, I was hoping to derive a bundle name from that
correspondence. But unfortunately, I can’t find a runtime call that helps,
either.
I’ve thought about other strategies, but since I actually want to put
extensionString {
func locate() -> String {}
}
in one framework and reference it in other frameworks, this looks to be
impossibly tricky. (I haven’t tried it, but I expect that if I tried, for
example, to parse out the module name from inside the locate() function, I’d
get the name of the module it is located in, not the module of the call-site.)
Sigh.
I guess I should file a suggestion radar about it.
Cheers,
Rick Aurbach
On Dec 1, 2016, at 6:36 PM, Jens Alfke
<j...@mooseyard.com<mailto:j...@mooseyard.com>> wrote:
Introspecting the call stack is possible, if somewhat ugly, using the backtrace
and backtrace_symbols functions (on macOS/iOS.) But all you get is a list of PC
and stack addresses, or function names. I don’t know how you’d go from those to
an NSBundle object. On cursory inspection I didn’t see any NSBundle methods for
finding out where in memory the associated code is loaded.
—Jens
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
