[swift-users] Accessing the bundle of the call-site

[Greg Parker]

On Darwin #dsohandle points to a Mach-O file header. You can pass that address to dyld but I don't see an easy way to pass it to NSBundle.

This might work:
1. Pass #dsohandle to dladdr()
2. Pass the dli_fname returned by dladdr() to NSBundle(path:).


> On Dec 2, 2016, at 12:50 PM, Rick Aurbach <rlaurb at icloud.com> wrote:
> 
> Jordan,
> 
> I agree — #dsohandle is, indeed, little known. In fact, I’m having a devil of a time figuring out what it is and what I can do with it. It is clearly an UnsafeRawPointer, but to what?? 
> 
> Can you offer either a reference or a few lines of code that can help me get the information I need from it? [recall that I want the framework’s bundle so I can find it’s localized.strings file].
> 
> Cheers,
> 
> Rick Aurbach
> 
>> On Dec 2, 2016, at 12:56 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>> 
>> On Apple platforms, we'd probably prefer you use the little-known #dsoHandle, a magic pointer that's unique to the current dylib. Parsing out a module name seems incredibly brittle; the form of #function is not guaranteed to be stable or useful across Swift versions.
>> 
>> Jordan
>> 
>> 
>>> On Dec 2, 2016, at 10:35, Rick Aurbach via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>>> 
>>> That’s clever! Thank you; I’d probably never have thought of that.
>>> 
>>> Cheers,
>>> 
>>> Rick Aurbach
>>> 
>>>> On Dec 2, 2016, at 12:25 PM, Greg Parker <gparker at apple.com <mailto:gparker at apple.com>> wrote:
>>>> 
>>>>> 
>>>>> On Dec 2, 2016, at 9:44 AM, Rick Aurbach via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>>>>> 
>>>>> Does anyone know if it is possible to do the following in Swift 3.x? (I’ll describe the issue abstractly first, then give the use-case.)
>>>>> 
>>>>> Consider two modules: A and B. A could be either the main module of an application or an embedded framework. B is a different embedded framework.
>>>>> 
>>>>> Now A contains an public extension of class X which contains a function f(). Inside B, there is a reference to X.f(). Now what I want to do in f() is to access information (a module name or bundle name or bundle ID or something) that allows me to construct a Bundle object referring to B, without f() having any external knowledge of the organization of the application.
>>>>> 
>>>>> The use-case I’m thinking about is a localization extension of String that works in a multi-framework application architecture without requiring the caller to specify the name of the framework and/or module.
>>>>> 
>>>>> I.e., I want to write
>>>>> 
>>>>> 	extension String {
>>>>> 		func locate() -> String {…}
>>>>> 	}
>>>>> 
>>>>> and put this extension into framework “A”. Then, from framework “B”, I want to use this function from within a function f() and [somehow] figure out from the runtime what the bundle of “B” is, so that I can use it’s localized strings file.
>>>>> 
>>>>> I understand that from within the locate() method, I can use #function and from it, parse out the module name of “A” and then use the correspondence between module names and framework names to figure out the bundle of “A”. BUT what I want here is the bundle resource for “B”, not “A”.
>>>> 
>>>> You should be able to use a trick similar to the one that assert() uses to collect file and line numbers:
>>>> 
>>>>     func locate(caller: StaticString = #function) {
>>>>         // `caller` is the caller's #function
>>>>     }
>>>> 
>>>> 
>>>> -- 
>>>> Greg Parker     gparker at apple.com <mailto:gparker at apple.com>     Runtime Wrangler
>>> 
>>> _______________________________________________
>>> swift-users mailing list
>>> swift-users at swift.org <mailto:swift-users at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-users <https://lists.swift.org/mailman/listinfo/swift-users>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20161202/95c9a369/attachment.html>