[CMake] Problem with LINK_DIRECTORIES

[David Cole]

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 <rcdailey at gmail.com> wrote:
> On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling <mhertling at 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
>