Re: Dylib and parent application symbol access
Re: Dylib and parent application symbol access
- Subject: Re: Dylib and parent application symbol access
- From: mark <email@hidden>
- Date: Tue, 10 Jan 2012 22:03:05 +1300
Hi Mark,
Wade Tregaskis skrev 2012-01-10 03:05:
The dylib project is intended to be an SDK so 3rd parties can
write their own plugin.
The project has to be stand alone and somehow link to the APP.
Then your library is essentially a framework, for the purposes of
this discussion. So the question is why you have your library
depending on your app? The typical pattern is to have your app
call into the plug-in library, registering callbacks or similar if
necessary.
Exactly, how come you need to have it depend on the application ?
The normal thing to do when designing plugin systems is to have a
defined API which the APP knows about and the plugin implements,
i.e. there should be no dependency towards the APP.
The parent APP has exported functions in the form of
RegisterFunction, RegisterFilter, ... .
I found it easier for the lib to register what functionality it has
this way as oppsed to the APP querying what functions it has.
Then the APP just loads whatever plugin it finds conforming to the
API (this you'll need to define yourself what that means). You'd be
using dlopen for this.
Check this thread on stackoverflow for some ideas:
http://stackoverflow.com/questions/1516476/how-to-create-some-class-from-dllconstructor-in-dll
Regards,
/Rob
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
My mistake.
I believed you could actually do it (Waaaayyyy back in CW days you
could use a stub library to fill in for it. I made the mistake you
can do it now).
I assumed because an NSBundle could link to it's parent APP's
exported functions/symbols, a dylib could.
Oh well. Thanks for the info.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden