[CMake] Problem with LINK_DIRECTORIES

[Alexander Neundorf]

On Monday 14 November 2011, Robert Dailey 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.


You can set CMAKE_PREFIX_PATH, and cmake will automatically look in the lib/ 
and include/ subdirectories of those.

Alex