[Cmake] Automated library dependencies

[Bill Hoffman]

If A uses library X, then B must use X.   I do not think that
is the question.   The problem is that X does not always come with
a full path, and may require an additional LINK_DIRECTORIES.  However,
if the UsePackage.cmake file was written correctly this should not be
a problem.   This does not happen within a single project, but only when
one project uses another project.   For VTK and ITK this is not a problem
because the UseVTK and UseITK files always add the correct LINK_DIRECTORIES for
the entire project, (they also use a single directory for the libraries.)


-Bill


At 11:11 AM 1/24/2003 +0000, John Biddiscombe wrote:
>Target A uses some library X
>Target B links against target A, but has no knowledge of X
>Cmake puts X in the link line for B but doesn't supply the path.
>
>Builds do not work. The unsuspecting user has to put paths in manually.
>
>B should not link against X.
>
>" 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."
>
>I vote the "Feature" be corrected.
>
>JB
>
>
>
>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.
>_______________________________________________
>Cmake mailing list
>Cmake at public.kitware.com
>http://public.kitware.com/mailman/listinfo/cmake
>_______________________________________________
>Cmake mailing list
>Cmake at public.kitware.com
>http://public.kitware.com/mailman/listinfo/cmake