Re: [CMake] Problem with LINK_DIRECTORIES
On 11/14/2011 09:15 PM, Robert Dailey wrote:
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling mhertl...@online.dewrote:
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
Re: [CMake] Problem with LINK_DIRECTORIES
On Tue, Nov 15, 2011 at 4:49 AM, Michael Hertling mhertl...@online.dewrote:
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
[CMake] Problem with LINK_DIRECTORIES
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
Re: [CMake] Problem with LINK_DIRECTORIES
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
Re: [CMake] Problem with LINK_DIRECTORIES
On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild them...@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. 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
Re: [CMake] Problem with LINK_DIRECTORIES
On 11/14/2011 03:36 PM, Robert Dailey wrote: On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild them...@gmail.com mailto:them...@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. 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
Re: [CMake] Problem with LINK_DIRECTORIES
On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey rcdai...@gmail.com wrote: On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild them...@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. 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
Re: [CMake] Problem with LINK_DIRECTORIES
On Mon, Nov 14, 2011 at 11:00 AM, David Cole david.c...@kitware.com wrote: On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey rcdai...@gmail.com wrote: On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild them...@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. -- 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
Re: [CMake] Problem with LINK_DIRECTORIES
On 14 November 2011 17:17, Robert Dailey rcdai...@gmail.com 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
Re: [CMake] Problem with LINK_DIRECTORIES
On 11/14/2011 06:17 PM, Robert Dailey wrote:
On Mon, Nov 14, 2011 at 11:00 AM, David Cole david.c...@kitware.com wrote:
On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey rcdai...@gmail.com wrote:
On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild them...@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.
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
Re: [CMake] Problem with LINK_DIRECTORIES
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling mhertl...@online.dewrote:
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
Re: [CMake] Problem with LINK_DIRECTORIES
On Monday 14 November 2011, Robert Dailey wrote:
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling
mhertl...@online.dewrote:
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
Re: [CMake] Problem with LINK_DIRECTORIES
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 rcdai...@gmail.com wrote:
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling mhertl...@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.
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
Re: [CMake] Problem with LINK_DIRECTORIES
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 rcdai...@gmail.com wrote:
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling mhertl...@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.
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
Re: [CMake] Problem with LINK_DIRECTORIES
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 clin...@elemtech.comwrote:
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 rcdai...@gmail.com
wrote:
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling mhertl...@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.
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
Re: [CMake] Problem with LINK_DIRECTORIES
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
clin...@elemtech.comwrote:
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 rcdai...@gmail.com
wrote:
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling
mhertl...@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.
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
