On Monday 14 November 2011, Robert Dailey wrote: > 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.
You can set CMAKE_PREFIX_PATH, and cmake will automatically look in the lib/ and include/ subdirectories of those. Alex -- 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