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 <rcdai...@gmail.com> 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. > 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