[Qt-interest] plugin fails to load with uresolved links to another plugin

[Kishore]

On Wednesday 16 Jun 2010 6:38:44 pm Andreas Pakulat wrote:
> On 16.06.10 18:07:55, Kishore wrote:
> > On Wednesday 16 Jun 2010 5:36:30 pm Thiago Macieira wrote:
> > > Em Quarta-feira 16 Junho 2010, às 13:51:58, Kishore escreveu:
> > > > like with many other applications is that plugin A depends on
> > > > plugin B.
> > > 
> > > That is not a normal situation.
> > > 
> > > Plugins don't depend on each other. That's why they are called
> > > "plugins".
> > > 
> > > Something that can be depend on is called "library". You link to it and
> > > the system will automatically load it.
> > > 
> > > > Now, everything works fine if i declare that plugin A depends on B
> > > > using the TARGET_LINK_LIBRARIES() (I use the CMake build system)
> > > > function. But for this to work, i have to declare both A and B as
> > > > SHARED instead of MODULE libraries.
> > > 
> > > That's what the effect of what I said above.
> > 
> > That is what i was told by Andreas too in the other list. Perhaps i
> > misunderstand this post too
> > http://labs.trolltech.com/blogs/2010/04/29/best-
> > practices-when-implementing-iplugin-methods/
> > 
> > Does this mean that plugin A (the dependent) cannot call API in plugin B?
> > I am confused since several posts on the net seem to suggest that this
> > is possible.
> 
> Right, you can only call functions from shared libraries, not from other
> plugins. One of the main points of having plugins is to be able to exchange
> them, this means that a certain plugin A must not have a direct dependency
> on the API or implementing of a plugin B.
> 
> Dependencies between plugins are usually expressed by using pure virtual
> classes declared in a header-only way. This way plugin A doesn't need to
> link against anything to be able to use the interface. The second piece is
> a central library that manages all loaded plugins and allows plugin A to
> retrieve a pointer to a plugin that implements the given interface. Then
> you can call the methods on the interface from plugin A without having to
> care wether its plugin B, E or Q implementing that interface.

And this central library does not understand the specific interfaces and hence 
maintains pointers to the "registered" objects as void * pointers. and then 
any function searching for a specific interface, iterates the list dynamic 
casting each void * to the interface. If the cast succeeds, it has found what 
it was looking for. registration of objects to the object pool happens at 
plugin load time.

That does clear somethings. The meaning of dependency here is that if A 
depends on B then it means that after A has loaded and initialized B should be 
notified as it is expected to do something with one or more of the registered 
objects registered by A.
-- 
Cheers!
Kishore