Re: Accessing the bundle of the call-site
Re: Accessing the bundle of the call-site
- Subject: Re: Accessing the bundle of the call-site
- From: Rick Aurbach <email@hidden>
- Date: Fri, 02 Dec 2016 01:21:21 -0500
- Acceptlanguage: en-US
- Thread-topic: Accessing the bundle of the call-site
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 <email@hidden<mailto:email@hidden>> 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 (email@hidden)
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:
This email sent to email@hidden