[CMake] Problem with LINK_DIRECTORIES

Mon Nov 14 15:51:49 EST 2011

What is the difference between CMAKE_LINK_LIBRARY_SUFFIX and
CMAKE_IMPORT_LIBRARY_SUFFIX? Which should I use?

---------
Robert Dailey

On Mon, Nov 14, 2011 at 2:49 PM, Clinton Stimpson <clinton at elemtech.com>wrote:

>
> That's what I do sometimes.  To make that easier, CMake gives some
> convenience
> variables for library prefixes and suffixes if you are on multiple
> platforms.
>
> Clint
>
> On Monday, November 14, 2011 01:20:29 pm David Cole wrote:
> > If you already know where all the libraries are, please just use the
> > full paths to those libraries, and do not use find_library.
> >
> > On Mon, Nov 14, 2011 at 3:15 PM, Robert Dailey <rcdailey at gmail.com>
> wrote:
> > > 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.
> > > --
> > >
> > > Powered by www.kitware.com
> > >
> > > Visit other Kitware open-source projects at
> > > http://www.kitware.com/opensource/opensource.html
> > >
> > > Please keep messages on-topic and check the CMake FAQ at:
> > > http://www.cmake.org/Wiki/CMake_FAQ
> > >
> > > Follow this link to subscribe/unsubscribe:
> > > http://www.cmake.org/mailman/listinfo/cmake
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.cmake.org/mailman/listinfo/cmake
>
> --
> Clinton Stimpson
> Elemental Technologies, Inc
> Computational Simulation Software, LLC
> www.csimsoft.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111114/556ebce1/attachment-0001.htm>