[CMake] Problem with LINK_DIRECTORIES

[Robert Dailey]

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.

For each target I simply create a list of my libs, like so:

set( libraries zlib libbdb47 )

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111114/16da068c/attachment.htm>