[CMake] third party library dependencies

[Marcel Loose]

On Fri, 2009-12-18 at 08:54 -0800, Jed Brown wrote:
> On Fri, 18 Dec 2009 10:19:05 +0100, "Marcel Loose" <loose at astron.nl> wrote:
> > Hi Roman,
> > 
> > Not in a portable way. I'm not too familiar with Windows, but on Linux
> > you can do this when libA is a shared library that has its dependency on
> > libB linked in (e.g. ldd libA.so will tell you this). When linking in
> > static libraries you're out of luck. 
> 
> With shared libraries, you need not and *should not* explicitly link
> recursive dependencies.  If you have both static and shared libraries,
> the output of ldd could be used to find the recursive deps needed to
> link statically.  This sucks and the logic to determine whether to put
> recursive deps in FOO_LIBRARIES ends up going in FindFoo.cmake which is
> insane.  FWIW, pkg-config has Libs.private for this purpose.
> 
> Finally, it would be nice to easily associate a symbol with a call to
> find_library.  That is, suppose libA links to libB and libC, but libA
> never exposes libB or libC to users.  To do the right thing (without
> abusing ldd), FindA.cmake needs to try linking with just -lA (which will
> work with all shared libs), then try with -lA -lB and -lA -lC before
> falling back to -lA -lB -lC (which is required when all libs are
> static).  A better way which does not have exponential complexity would
> be to declare that the symbol "B_Foo" belongs with a libB and "C_Bar"
> belongs with a libC.  So when linking with -lA fails, libB would be
> added exactly when B_Foo is undefined.
> 
> Jed

Hi Jed,

Why do you consider explicit linking of recursive dependencies a bad
thing? It's superfluous, I agree, but there's no harm in it, right?

Best regards,
Marcel Loose.