<div><div class="gmail_quote">On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling <span dir="ltr">&lt;<a href="mailto:mhertling@online.de">mhertling@online.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="HOEnZb"><div class="h5">On 11/14/2011 06:17 PM, Robert Dailey wrote:<br>
&gt; Well maybe you can tell me I&#39;m doing this wrong then, but based on how I am<br>
&gt; currently setting up my third party libraries, it is required.<br>
&gt;<br>
&gt; So basically all third party libraries we use are not installed<br>
&gt; individually, instead we have a server on our intranet that contains<br>
&gt; precompiled versions of all libraries in a specific and consistent<br>
&gt; hierarchy. For this reason, it doesn&#39;t make sense to use find_library(),<br>
&gt; which would normally always give you absolute paths to your library files<br>
&gt; and thus link_directories() would not be needed.<br>
&gt;<br>
&gt; Instead I have a script in CMake that iterates each third party library and<br>
&gt; adds its lib link directory to a list. When done I take this whole list of<br>
&gt; link directories and pass it to link_directories() in my top level<br>
&gt; CMakeLists file, this way each and every project will include all of the<br>
&gt; third party library lib directories to have access to them.<br>
<br>
</div></div>Instead of populating a list with the libraries&#39; directories, you might<br>
set up one variable for each library containing the latter&#39;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>
<div class="im"><br>
&gt; For each target I simply create a list of my libs, like so:<br>
&gt;<br>
&gt; set( libraries zlib libbdb47 )<br>
<br>
</div>SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})<br>
<div class="im"><br>
&gt; I pass each one of these to target_link_libraries() and I leave it up to<br>
&gt; the compiler to search for where to find the file in the provided link<br>
&gt; directories.<br>
<br>
</div>An unrestricted use of LINK_DIRECTORIES() means asking for trouble;<br>
especially with numerous directories, there&#39;s a growing probability<br>
that the -L option will lure the linker into a wrong directory some<br>
day. There&#39;re even situations which can&#39;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&#39; 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?</blockquote><div><br></div>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.<div>
<br></div><div>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.</div>
<div><br></div><div>Why should I let CMake search &amp; 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.</div>
<div><br></div><div>Another issue is that 80% of the libraries we use do not have a pre-packaged Find module provided by CMake. This means I&#39;d end up writing 80% of the find modules myself. This is a lot of work for no perceived benefit.</div>
<div><br></div><div>With my points made and circumstances explained, can you still give me a good reason to use find_library?</div><div><br></div><div>I understand and agree with the issues that come with using link_directories(), however I haven&#39;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&#39;m replacing.</div>
</div></div>