[CMake] Problem with LINK_DIRECTORIES

[Michael Hertling]

On 11/14/2011 06:17 PM, Robert Dailey wrote:
> On Mon, Nov 14, 2011 at 11:00 AM, David Cole <david.cole at kitware.com> wrote:
> 
>> On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey <rcdailey at gmail.com> wrote:
>>> On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild <themiwi at 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