[CMake] plugin dependencies and TARGET_LINK_LIBRARIES()

[Kishore]

On Wednesday 16 Jun 2010 8:51:27 am you wrote:
> On Tuesday 15 Jun 2010 11:32:17 pm Andreas Pakulat wrote:
> > On 15.06.10 22:18:04, Kishore wrote:
> > > How do i inform cmake when building a module that it depends on another
> > > module? Does cmake need to even know that?
> > > 
> > > I am building a plugin based qt application (my first time with
> > > plugins) and my situlation like with many other applications is that
> > > plugin A depends on plugin B. In my application i take care to load
> > > plugin B before A. However, loading plugin A fails complaining that it
> > > could not resolve links which are in B. plugin B which only depends on
> > > the application loads fine.
> > > 
> > > Now, everything works fine if i declare that plugin A depends on B
> > > using the TARGET_LINK_LIBRARIES() function. But for this to work, i
> > > have to declare both A and B as SHARED instead of MODULE libraries.
> > > 
> > > What is the right way to go?
> > 
> > Thats not a real plugin system, plugins don't link against other plugins
> > directly. Your options are:
> > 
> > - extract the code from B that you need in A into the shared lib (that
> > 
> >   you should already have) that both A and B (and your application) link
> >   against
> 
> This i could do...
> 
> > - provide an interface header from B and a way in your app for a plugin
> > 
> >   to get a pointer to such an interface. Then provide the necessary api
> >   functions you need in A in that interface as pure virtual. That way A
> >   can use this virtual interface to get at the B functions without
> >   directly linking against it.
> 
> This I don't fully understand. If A depends in B which would mean that it
> extends functionality in B, it would have to call some methods in B. No?
> 
> In my implementation, I have a base class in B that has some pure virtual
> functions that are implemented by a class in A. On loading A it registers a
> factory object declaring availability of a certain functionality. The
> registration API resides in B.
> 
> Apparently, I do not properly understand the concept of one plugin
> depending on another.

This post has been moved to the more appropriate qt-interest mailing list.
-- 
Cheers!
Kishore