>From the Modules/Platform/* files, it looks like the only difference between >the two is when using CYGWIN or MinGW. I'm not sure which to use.
Clint On Monday, November 14, 2011 01:51:49 pm Robert Dailey wrote: > 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 <[email protected]>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 <[email protected]> > > > > wrote: > > > > On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling > > > > <[email protected] > > > > > > > > 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 -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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
