On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling <mhertl...@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