[CMake] add_subdirectory and link_directories

Rolf Eike Beer eike at sf-mail.de
Tue Jan 11 03:57:49 EST 2011


> On 01/10/2011 06:24 PM, Andrea Galeazzi wrote:
>> I've got a main project which relies on several sub-library projects, so
>> the main CMakeLists.txt
>> add_subdirectory("W:/Omega/Kernel"
>> "${CMAKE_CURRENT_BINARY_DIR}/myLib1")
>> ...........
>> and then I also specify the directory where all libraries have been
>> built (by setting ARCHIVE_OUTPUT_DIRECTORY for each library)
>> link_directories("${ROOT_LIB}/{CMAKE_SYSTEM_NAME}/${CMAKE_BUILD_TYPE}")
>> Anyway I noticed that the build process works fine also without
>> declaring the row above.
>> My question: is specifying  link_directories useless when I use
>> add_subdirectory in order to build a library? If yes, is that true
>> regardless the target (I only tested it in VS2010 and MinGW)?
>
> Since CMake prefers to specify libraries by path instead of using -l/-L
> or the like, there's usually no need for the LINK_DIRECTORIES() command,
> IMO. For the project's targets, CMake tracks their paths by itself and
> takes OUTPUT_DIRECTORY properties and explicit binary directories into
> account; the find modules and configuration files of external packages
> also use full paths for their libraries, either immediately or via the
> IMPORTED_LOCATION properties of imported targets, so you should rarely
> have to use the LINK_DIRECTORIES() command, at least for new CMakified
> projects. Moreover, it might involve the danger of luring the linker
> into the wrong directories, see [1], and makes it harder to choose a
> static library instead of a shared one, see [2]. Thus, I'd recommend
> against using LINK_DIRECTORIES() unless there's a good reason for it.

Since I've seen the very same question many times on IRC (and always gave
basically the same advise) could you please make a patch to the CMake
documentation for LINK_DIRECTORIES() from this so new users are aware that
they are looking at the wrong place? When you come from plain Makefiles
you are expecting to do all those -Lfoo stuff and don't think that CMake
will do all that stuff for you.

Eike


More information about the CMake mailing list