On 11/14/2011 06:17 PM, Robert Dailey wrote: > On Mon, Nov 14, 2011 at 11:00 AM, David Cole <david.c...@kitware.com> wrote: > >> On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey <rcdai...@gmail.com> wrote: >>> On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild <them...@gmail.com> wrote: >>>> >>>> Hi Arun >>>> Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost. >>> >>> I don't really agree with this advice. There are circumstances where >>> link_directories() is absolutely necessary, so advocating to completely >>> avoid it isn't really a one size fits all scenario. >> >> I agree with the advice entirely. link_directories is completely >> *un*necessary if you follow the other advice which is to always use >> full path names to library files (or CMake target names) when calling >> target_link_libraries. >> >> I never use link_directories. > > > 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? Regards, Michael -- 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