What is the difference between CMAKE_LINK_LIBRARY_SUFFIX and CMAKE_IMPORT_LIBRARY_SUFFIX? Which should I use?<br clear="all"><div><br></div><div>---------</div>Robert Dailey<br>
<br><br><div class="gmail_quote">On Mon, Nov 14, 2011 at 2:49 PM, Clinton Stimpson <span dir="ltr"><<a href="mailto:clinton@elemtech.com">clinton@elemtech.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
That's what I do sometimes. To make that easier, CMake gives some convenience<br>
variables for library prefixes and suffixes if you are on multiple platforms.<br>
<br>
Clint<br>
<div class="HOEnZb"><div class="h5"><br>
On Monday, November 14, 2011 01:20:29 pm David Cole wrote:<br>
> If you already know where all the libraries are, please just use the<br>
> full paths to those libraries, and do not use find_library.<br>
><br>
> On Mon, Nov 14, 2011 at 3:15 PM, Robert Dailey <<a href="mailto:rcdailey@gmail.com">rcdailey@gmail.com</a>> wrote:<br>
> > On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling <<a href="mailto:mhertling@online.de">mhertling@online.de</a>><br>
> ><br>
> > wrote:<br>
> >> On 11/14/2011 06:17 PM, Robert Dailey wrote:<br>
> >> > Well maybe you can tell me I'm doing this wrong then, but based on how<br>
> >> >I<br>
> >> ><br>
> >> > am<br>
> >> > currently setting up my third party libraries, it is required.<br>
> >> ><br>
> >> > So basically all third party libraries we use are not installed<br>
> >> > individually, instead we have a server on our intranet that contains<br>
> >> > precompiled versions of all libraries in a specific and consistent<br>
> >> > hierarchy. For this reason, it doesn't make sense to use<br>
> >> > find_library(), which would normally always give you absolute paths<br>
> >> > to your library files<br>
> >> > and thus link_directories() would not be needed.<br>
> >> ><br>
> >> > Instead I have a script in CMake that iterates each third party<br>
> >> > library and<br>
> >> > adds its lib link directory to a list. When done I take this whole<br>
> >> > list of<br>
> >> > link directories and pass it to link_directories() in my top level<br>
> >> > CMakeLists file, this way each and every project will include all of<br>
> >> > the third party library lib directories to have access to them.<br>
> >><br>
> >> Instead of populating a list with the libraries' directories, you might<br>
> >> set up one variable for each library containing the latter's full path,<br>
> >> e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level<br>
> >> CMakeLists.txt, these variables propagate to subordinate CMakeLists.txt<br>
> >> files and, thus, will be known wherever they are needed in your project.<br>
> >><br>
> >> > For each target I simply create a list of my libs, like so:<br>
> >> ><br>
> >> > set( libraries zlib libbdb47 )<br>
> >><br>
> >> SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})<br>
> >><br>
> >> > I pass each one of these to target_link_libraries() and I leave it up<br>
> >> > to the compiler to search for where to find the file in the provided<br>
> >> > link directories.<br>
> >><br>
> >> An unrestricted use of LINK_DIRECTORIES() means asking for trouble;<br>
> >> especially with numerous directories, there's a growing probability<br>
> >> that the -L option will lure the linker into a wrong directory some<br>
> >> day. There're even situations which can't be resolved with -L/-l at<br>
> >> all: Suppose you have a directory x with liba.so and libb.so, and a<br>
> >> directory y with different versions of lib{a,b}.so. Suppose further<br>
> >> you want to link against x/liba.so and y/libb.so. How do you achieve<br>
> >> this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,<br>
> >> insisting on the use of LINK_DIRECTORIES() limits the possibilities<br>
> >> how to organize the libraries on your intranet server. IMO, these<br>
> >> are actual drawbacks. OTOH, you must know the libaries' locations<br>
> >> to use LINK_DIRECTORIES(), and the libraries must be known anyway,<br>
> >> so why not join the locations to the libraries and use full paths?<br>
> ><br>
> > Problem is, if I end up using find_library(), I will have to provide hint<br>
> > search directories for each and every single library, and there are about<br>
> > 20 of them. This to me is the same as just generating a list of<br>
> > directories and including those directly, and a lot less trouble.<br>
> > find_library() is great and I really wanted to use it for this, but to me<br>
> > the benefits of using it diminish when we are not using third party<br>
> > libraries installed in a non deterministic location. If a user installs<br>
> > the third party libraries in different locations on each of their<br>
> > machines, and different versions, it makes more sense to use it in that<br>
> > case.<br>
> > Why should I let CMake search & find a library when I already know where<br>
> > it is? Simply to get absolute paths to those libraries? If I want<br>
> > absolute paths I can think of much better ways to do<br>
> > it, preferably through string concatenation.<br>
> > Another issue is that 80% of the libraries we use do not have a<br>
> > pre-packaged Find module provided by CMake. This means I'd end up<br>
> > writing 80% of the find modules myself. This is a lot of work for no<br>
> > perceived benefit.<br>
> > With my points made and circumstances explained, can you still give me a<br>
> > good reason to use find_library?<br>
> > I understand and agree with the issues that come with using<br>
> > link_directories(), however I haven't run into those issues yet and our<br>
> > consistent organization of third party libraries on our intranet server<br>
> > are carry over from our legacy build system that I'm replacing.<br>
> > --<br>
> ><br>
> > Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
> ><br>
> > Visit other Kitware open-source projects at<br>
> > <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
> ><br>
> > Please keep messages on-topic and check the CMake FAQ at:<br>
> > <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
> ><br>
> > Follow this link to subscribe/unsubscribe:<br>
> > <a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
><br>
> --<br>
><br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Please keep messages on-topic and check the CMake FAQ at:<br>
> <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Clinton Stimpson<br>
Elemental Technologies, Inc<br>
Computational Simulation Software, LLC<br>
<a href="http://www.csimsoft.com" target="_blank">www.csimsoft.com</a><br>
</font></span></blockquote></div><br>