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

[Andreas Pakulat]

On 16.06.10 22:53:08, Kishore wrote:
> 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.

Well, usually you'd have some kind of IPlugin base class that all
plugins subclass provided by the central library. That is to give
plugins a proper initialization and shutdown hook so they can be
loaded/unloaded properly. And possibly also for some common things like
a plugin name for example (to show in the gui eventually).

Andreas

-- 
You will forget that you ever knew me.