[CMake] Problem with LINK_DIRECTORIES

Robert Dailey rcdailey at gmail.com
Mon Nov 14 15:15:48 EST 2011


On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling <mhertling at online.de>wrote:

> On 11/14/2011 06:17 PM, Robert Dailey wrote:
> > Well maybe you can tell me I'm doing this wrong then, but based on how I
> am
> > currently setting up my third party libraries, it is required.
> >
> > So basically all third party libraries we use are not installed
> > individually, instead we have a server on our intranet that contains
> > precompiled versions of all libraries in a specific and consistent
> > hierarchy. For this reason, it doesn't make sense to use find_library(),
> > which would normally always give you absolute paths to your library files
> > and thus link_directories() would not be needed.
> >
> > Instead I have a script in CMake that iterates each third party library
> and
> > adds its lib link directory to a list. When done I take this whole list
> of
> > link directories and pass it to link_directories() in my top level
> > CMakeLists file, this way each and every project will include all of the
> > third party library lib directories to have access to them.
>
> Instead of populating a list with the libraries' directories, you might
> set up one variable for each library containing the latter's full path,
> e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level
> CMakeLists.txt, these variables propagate to subordinate CMakeLists.txt
> files and, thus, will be known wherever they are needed in your project.
>
> > For each target I simply create a list of my libs, like so:
> >
> > set( libraries zlib libbdb47 )
>
> SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
>
> > I pass each one of these to target_link_libraries() and I leave it up to
> > the compiler to search for where to find the file in the provided link
> > directories.
>
> An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
> especially with numerous directories, there's a growing probability
> that the -L option will lure the linker into a wrong directory some
> day. There're even situations which can't be resolved with -L/-l at
> all: Suppose you have a directory x with liba.so and libb.so, and a
> directory y with different versions of lib{a,b}.so. Suppose further
> you want to link against x/liba.so and y/libb.so. How do you achieve
> this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
> insisting on the use of LINK_DIRECTORIES() limits the possibilities
> how to organize the libraries on your intranet server. IMO, these
> are actual drawbacks. OTOH, you must know the libaries' locations
> to use LINK_DIRECTORIES(), and the libraries must be known anyway,
> so why not join the locations to the libraries and use full paths?


Problem is, if I end up using find_library(), I will have to provide hint
search directories for each and every single library, and there are about
20 of them. This to me is the same as just generating a list of directories
and including those directly, and a lot less trouble.

find_library() is great and I really wanted to use it for this, but to me
the benefits of using it diminish when we are not using third party
libraries installed in a non deterministic location. If a user installs the
third party libraries in different locations on each of their machines, and
different versions, it makes more sense to use it in that case.

Why should I let CMake search & find a library when I already know where it
is? Simply to get absolute paths to those libraries? If I want absolute
paths I can think of much better ways to do it, preferably through string
concatenation.

Another issue is that 80% of the libraries we use do not have a
pre-packaged Find module provided by CMake. This means I'd end up writing
80% of the find modules myself. This is a lot of work for no perceived
benefit.

With my points made and circumstances explained, can you still give me a
good reason to use find_library?

I understand and agree with the issues that come with using
link_directories(), however I haven't run into those issues yet and our
consistent organization of third party libraries on our intranet server are
carry over from our legacy build system that I'm replacing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111114/0649ceb9/attachment-0001.htm>


More information about the CMake mailing list