[CMake] Problem with LINK_DIRECTORIES

[Robert Dailey]

On Tue, Nov 15, 2011 at 4:49 AM, Michael Hertling <mhertling at online.de>wrote:
>
> As David has outlined in the meantime, the advice is not about using
> FIND_LIBRARY() - which has not been mentioned a single time - but to
> assemble full paths from the libraries' directories and the libraries
> themselves, instead of collecting the directories and passing them to
> LINK_DIRECTORIES(). I doubt that the latter really means less trouble.
>

I mentioned find_library() because I have used it in the past to obtain
absolute paths to my third party libraries and it worked very well. It's a
solution to the problem, so I don't see any problem in talking about it.

Exactly; do this to get full paths to your libraries, use these paths
> in TARGET_LINK_LIBRARIES() and eliminate LINK_DIRECTORIES() from your
> project. Besides, "knowing where it is" means an assumption of your
> project on your system's administrational/organizational setup, and
> relying on such an assumption means that you can't change this setup
> without risking your project's breakage. Finally, LINK_DIRECTORIES()
> dramatically increases this risk because it makes your project subtly
> vunerable to changes in the third-party libraries' directory hierarchy.
>

The setup I have chosen to eliminate link_directories() involves globbing
everything in each library's 'lib' directory and storing that in an alias,
such as 'openssl'. When a project specifies this alias, it looks into the
openssl_THIRD_PARTY_LIBS internal cache variable which is created by the
third-party lookup system I created. The globbed *.lib files will be listed
in that cache variable and can be added via target_link_libraries(). All of
this happens behind the scenes, all the user needs to specify in the
project CMakeLists files is 'openssl' to get those libs.

Depending on a simple and consistent structure on a NAS for our third party
libraries isn't a big deal and won't change. The only change it will endure
is when we add new libraries. The structure is like so:

\\nas\third_party\openssl\1.0\msvc71\debug\lib (there is also 'include' and
'bin')

This way of including libs works great for what we do. It's simple and
mostly automated & transparent.

When considering libraries that have a LOT of libs, and you don't want to
blindly include them all, we simply code special logic in our core CMake
files to handle those differently. For example, consider boost. If the user
specifies the third party library 'boost', it will include over 20 libs for
all of the different components. Instead, I have a syntax like so:

boost_filesystem

In this case I strip out the "boost_" part, leaving "filesystem", and I
append that to whatever our boost library format is, like so: boost_{0}.lib
and make a full path to that, pass it to target_link_libraries().

I don't like the core CMake module knowing about specific third party
libraries and having logic for them, but I may abstract this out later into
some sort of generic logic where the definitions are stored in a separate
file.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111115/228adb79/attachment.htm>