On Samstag, 10. August 2013 17:13:28 CEST, Pali Rohár wrote:
I think this option is cleaner solution
Having core and Plugins operating on a common interface via a common shared library is a clean dependency chain. Whatever you can bring against it, it's for sure not "dirty". I understood you read Thiagos reply? Here's a rule of thumb: in doubt, Thiago's always right. Sucks, but it's true. Leaving aside that a statically linked plugin is hardly an "plug-in" but a "compiled-in" and could be very much done this way instead of the plugin detour (as QStyle does for the builtin uglyness) ....
as creating some new shared library only for exporting symbols to other shared plugin libraries...
... you create a common dependency for common functionality. That's common. Of course it would be possible to resolve the entire required API at runtime or even implement plugins as subprocesses, intercom by I/O - the question is "how loose do you want to bind this and why" - and what would be worth to mimic the linker resolution in your plugin loading? Having a shared library gets plugin developers encapsulated API and dependecy as well as compile-time instead of runtime failures and playing on symbol visibility, esp. between dynamic and static linkage, is a rather fragile system (special compiler/linker/flags ...) and a can of worms (hello Bsymbolic troubles) as well. Having application and plugin share a common library is a widely used concept, so I think you need to really explain what you object so much about this path - aside "oh no, one more shared lib" (we're not near any limits in this regard) Cheers, Thomas
