[Cmake] Automated library dependencies

[Miller, James V (Research)]

The example in point is that we are have a project where, if it can 
find VXL, will add some VTK classes that are implemented using VXL
algorithms.  This particular library links fine.

There is an executable and library in this project in a tree parallel 
to the first library that uses VXL that link against this first library.  

These targets are properly getting the VXL libraries appended to their 
link lines, however, the propagation of the LINK_DIRECTORIES is not done.

This is using the standard UseVXL.cmake code that establishes the
LINK_DIRECTORIES.

I can solve this a number of ways (for instance duplicating the 
LINK_DIRECTORIES call for the second library or executable, or I could 
search for VXL in a toplevel directory).  But this is not as clean as 
one would think it could be.

Essentially, my project ends up with a line 

LINK_DIRECTORIES ( ${VXL_LIBRARY_PATH} ) 

from the UseVXL.cmake file.

As you point out, this directory path is a full path in the CMakeCache.txt.

So while VXL is an external package, it is not "installed" and the second library is not going to be
able to find it without a hint. It should use the same hint that the first library used.

Otherwise, you could end up with this scenario:

1) Library B is built using the VXL libraries from a VXL build tree.
2) Library A "inherits" the VXL libraries from its dependency on library B.
3) Library A finds VXL libraries in some system directory because the particular computer had an
installed version of VXL.

So library A links against a potentially different VXL than library B.

I am guessing the same situation could apply to INCLUDE_DIRECTORIES().

Jim




> -----Original Message-----
> From: Amitha Perera [mailto:perera at cs.rpi.edu]
> Sent: Tuesday, January 21, 2003 10:20 AM
> To: Miller, James V (Research)
> Cc: CMake developers (E-mail)
> Subject: Re: [Cmake] Automated library dependencies
> 
> 
> On Tue 21 Jan 2003, Miller, James V (Research) wrote:
> > What does not seem to be happening automatically is the propagation
> > of the LINK_DIRECTORIES that were used to build library B into the
> > LINK_DIRECTORIES that are needed for library A.  So if library B
> > uses an external package, library A will also link to that external
> > package but it won't know where to find that external package.
> 
> You might call this a "feature". I'll try to explain how it works, and
> we can then discuss whether the behaviour should change or not.
> 
> Keep in mind that CMake normally keeps full paths to everything. So,
> when you say FIND_LIBRARY( FOO_LIB foo /usr/local/lib ), it will set
> FOO_LIB=/usr/local/lib/libfoo.so. Notice how the path is embedded in
> the library name. Now, this whole path gets propagated to library A,
> to use your example. Therefore, library A will have the directory in
> which to find foo. Good.
> 
> Now suppose you do
>   LINK_DIRECTORIES( "/some/system/path" )
>   TARGET_LINK_LIBRARIES( B "-ljpeg" )
> all that will go forward is "-ljpeg". Therefore, A will not have the
> path to find jpeg. However, since it is an external library,
> presumably the system is able to find it, and so you *do not* need to
> know where it is. (Rather, where it was on the system that compiled A;
> it may not be in the same place in some other system.)
> 
> If you do
>   TARGET_LINK_LIBRARIES( B /some/system/path/libjpeg.so )
> then all will be well again. In general, if you use FIND_LIBRARY, this
> problem should not arise.
> 
> My feeling is that explicitly providing "-ljpeg" on the link line is
> specifying a "system" library, and the user is responsible for making
> sure it is found. I mean in the sense of a deliverable: you don't know
> where on the user's system to find this external library. But I admit
> the distinction is rather arbitrary and inconsistent.
> 
> >  (I assume this is only a problem when library A is not in a
> > subdirectory of library B).
> 
> Not really. If A is a subdirectory of B, then A will link fine, but if
> some executable outside of these two directories tries to link to A,
> you'll probably have the same error.
> 
> > Should the LINK_DIRECTORIES also be propagated from library B to
> > library A.  It is basically the same argument for why the link
> > libraries are propagated from library B to library A.
> 
> I think this *can* be done. I'll leave the policy decisions--should it
> be, and into which version--to others.
> 
> Amitha.
>