Problem with LINK_DIRECTORIES

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with LINK_DIRECTORIES

Arunmozhi
Hi,

For a static library target, I used TARGET_LINK_LIBRARIES and LINK_DIRECTORIES to link with a third party library. As we can see that in cmake, this linking information is propagated and used only in an executable/shared library target which depends on the former static library. But the issue is that only the TARGET_LINK_LIBRARIES is propagated and not the LINK_DIRECTORIES. This fails the linking of the executable/shared library target because it could not find the third party library.

I found this problem when generating for visual studio 2005. The problem might be there in other platforms also.

I feel that this behavior is an issue. Or am I missing something? Please let me know.

Regards,
Arun


--

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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with LINK_DIRECTORIES

Michael Wild
On 11/14/2011 11:46 AM, Arunmozhi wrote:

> Hi,
>
> For a static library target, I used TARGET_LINK_LIBRARIES and
> LINK_DIRECTORIES to link with a third party library. As we can see that
> in cmake, this linking information is propagated and used only in an
> executable/shared library target which depends on the former static
> library. But the issue is that only the TARGET_LINK_LIBRARIES is
> propagated and not the LINK_DIRECTORIES. This fails the linking of the
> executable/shared library target because it could not find the third
> party library.
>
> I found this problem when generating for visual studio 2005. The problem
> might be there in other platforms also.
>
> I feel that this behavior is an issue. Or am I missing something? Please
> let me know.
>
> Regards,
> Arun
>

Hi Arun

Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost.
Just pass the full path to the static library directly to
TARGET_LINK_LIBRARIES. This is much more robust and will avoid these
weird effects you are seeing.

HTH

Michael

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with LINK_DIRECTORIES

Robert Dailey
On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild <[hidden email]> 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.

What I've done is make sure that link_directories() is called from a parent level directory, so that all projects inherit the directories. In cases where you do not have a hierarchy setup like this, then call link_directories() once with the same directories before each call to add_executable, add_library, etc.

Also one unrelated note, but static libraries do not require any dependencies to be linked in when it is built. You only need your third party libraries in your shared library or executable that links against the static library in question.

Hope this helps. 

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with LINK_DIRECTORIES

Michael Wild
On 11/14/2011 03:36 PM, Robert Dailey wrote:

> On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild <[hidden email]
> <mailto:[hidden email]>> 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.

Pray tell, what scenario would that be? I'm really curious, because I
can't think of any...

>
> What I've done is make sure that link_directories() is called from a
> parent level directory, so that all projects inherit the directories. In
> cases where you do not have a hierarchy setup like this, then call
> link_directories() once with the same directories before each call to
> add_executable, add_library, etc.
>
> Also one unrelated note, but static libraries do not require any
> dependencies to be linked in when it is built. You only need your third
> party libraries in your shared library or executable that links against
> the static library in question.

The OP is talking about such a setup

a/CMakelists.txt:
----------------
add_library(a STATIC a.c)
# a uses foo internally, but doesn't expose this fact in its interface.
# clients of a should not need to know about a's implementation details,
# which is why we declare this dependency here and let CMake handle the
# rest.
target_link_libraries(a foo)

b/CMakeLists.txt
-----------------
add_executable(b b.c)
target_link_libraries(b a)


Michael
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with LINK_DIRECTORIES

David Cole
In reply to this post by Robert Dailey
On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey <[hidden email]> wrote:
> On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild <[hidden email]> 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.


> What I've done is make sure that link_directories() is called from a parent
> level directory, so that all projects inherit the directories. In cases
> where you do not have a hierarchy setup like this, then call
> link_directories() once with the same directories before each call to
> add_executable, add_library, etc.
> Also one unrelated note, but static libraries do not require any
> dependencies to be linked in when it is built. You only need your third
> party libraries in your shared library or executable that links against the
> static library in question.
> Hope this helps.
> --
>
> 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
>
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with LINK_DIRECTORIES

Robert Dailey
On Mon, Nov 14, 2011 at 11:00 AM, David Cole <[hidden email]> wrote:
On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey <[hidden email]> wrote:
> On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild <[hidden email]> 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.

--

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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with LINK_DIRECTORIES

Mateusz Loskot
On 14 November 2011 17:17, Robert Dailey <[hidden email]> wrote:
> 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.

A typical Linux user can say the same: I have all my libraries in /usr/lib
so it does not make sense to use find_library.
No point arguing if it would make sense or not.
Simply, find_library is a unified convention used by CMake, it works regardless
user-specific filesystem structure.

Simply, it would not hurt to use find_library().
Then, you can follow the CMake convention, without a need of custom
scripts, etc.

> 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.

IMO, you don't buy anything with this customisation.
Either CMake finds library and tells compiler "look, it's here"
or CMake + custom script approximates library location
and lets linker to find it.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org
--

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
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Re: Problem with LINK_DIRECTORIES

Michael Hertling
In reply to this post by Robert Dailey
On 11/14/2011 06:17 PM, Robert Dailey wrote:

> On Mon, Nov 14, 2011 at 11:00 AM, David Cole <[hidden email]> wrote:
>
>> On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey <[hidden email]> wrote:
>>> On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild <[hidden email]> 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.

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?

Regards,

Michael
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with LINK_DIRECTORIES

Robert Dailey
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with LINK_DIRECTORIES

Alexander Neundorf-3
On Monday 14 November 2011, Robert Dailey wrote:
> On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling
<[hidden email]>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
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with LINK_DIRECTORIES

David Cole
In reply to this post by Robert Dailey
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 <[hidden email]> wrote:

> On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling <[hidden email]>
> 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
>
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with LINK_DIRECTORIES

Clinton Stimpson

That's what I do sometimes.  To make that easier, CMake gives some convenience
variables for library prefixes and suffixes if you are on multiple platforms.

Clint

On Monday, November 14, 2011 01:20:29 pm David Cole wrote:

> 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 <[hidden email]> wrote:
> > On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling <[hidden email]>
> >
> > 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
>
> --
>
> 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

--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with LINK_DIRECTORIES

Robert Dailey
What is the difference between CMAKE_LINK_LIBRARY_SUFFIX and CMAKE_IMPORT_LIBRARY_SUFFIX? Which should I use?

---------
Robert Dailey


On Mon, Nov 14, 2011 at 2:49 PM, Clinton Stimpson <[hidden email]> wrote:

That's what I do sometimes.  To make that easier, CMake gives some convenience
variables for library prefixes and suffixes if you are on multiple platforms.

Clint

On Monday, November 14, 2011 01:20:29 pm David Cole wrote:
> 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 <[hidden email]> wrote:
> > On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling <[hidden email]>
> >
> > 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
>
> --
>
> 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

--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com


--

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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with LINK_DIRECTORIES

Clinton Stimpson

From the Modules/Platform/* files, it looks like the only difference between the
two is when using CYGWIN or MinGW.  I'm not sure which to use.

Clint

On Monday, November 14, 2011 01:51:49 pm Robert Dailey wrote:
> What is the difference between CMAKE_LINK_LIBRARY_SUFFIX and
> CMAKE_IMPORT_LIBRARY_SUFFIX? Which should I use?
>
> ---------
> Robert Dailey
>
> On Mon, Nov 14, 2011 at 2:49 PM, Clinton Stimpson
<[hidden email]>wrote:

> > That's what I do sometimes.  To make that easier, CMake gives some
> > convenience
> > variables for library prefixes and suffixes if you are on multiple
> > platforms.
> >
> > Clint
> >
> > On Monday, November 14, 2011 01:20:29 pm David Cole wrote:
> > > 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 <[hidden email]>
> >
> > wrote:
> > > > On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling
> > > > <[hidden email]
> > > >
> > > > 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
> > >
> > > --
> > >
> > > 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
> >
> > --
> > Clinton Stimpson
> > Elemental Technologies, Inc
> > Computational Simulation Software, LLC
> > www.csimsoft.com

--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with LINK_DIRECTORIES

Michael Hertling
In reply to this post by Robert Dailey
On 11/14/2011 09:15 PM, Robert Dailey wrote:

> On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling <[hidden email]>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.

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.

> 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.

Even if your third-party libraries' organization isn't subject to
change, so you don't need to use FIND_LIBARRY(), you might set up
variables with the libraries' full paths in the cache, i.e. using
SET(... CACHE FILEPATH ...), and preferably initialize them with
a separate file and the -C option. In this way, you do not need
to hard-code any paths in your project, and the user gains the
chance to manipulate each path on the command line or the GUI.

> 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.

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.

> 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.

Find modules are for FIND_PACKAGE(), and no one says that there
must be a find module for each of your third-party libraries.

> With my points made and circumstances explained, can you still give me a
> good reason to use find_library?

FIND_LIBRARY() has the secondary advantage that it automatically
searches for libraries in a platform-dependent manner through a
platform-independent interface, e.g. it can search for .lib files
as well as for .so files without the user's intervention. For this
reason, I often use FIND_LIBRARY() - in conjunction with PATHS and
NO_DEFAULT_PATH - even in configuration files for FIND_PACKAGE(),
which definitely know where the requested library is located.

> 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.

In this regard, the point is that using LINK_DIRECTORIES() - due to
its inherent booby-traps - restricts the possibilities to change the
third-party libraries' organization on your intranet server. If you
are willing to accept such a restriction, it's okay, of course. IMO,
it's completely unnecessary because the use of full paths in cached
variables - regardless if set up by FIND_LIBRARY() or initialized
via -C - makes your project by far more robust w.r.t. the external
libraries and provides additional means for the user to intervene.

Regards,

Michael
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Problem with LINK_DIRECTORIES

Robert Dailey
On Tue, Nov 15, 2011 at 4:49 AM, Michael Hertling <[hidden email]> 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.

--

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