[CMake] third party library dependencies
Is there an easy way to setup link dependencies between libraries not build using cmake? Lets say I have a system library A which depends on system library B. I then make an executable that uses code from A. I need to link against A and B, but as a user of just library A, I don't want to worry about that. Does cmake have a facility to define such a hierarchy/dependency chain so that I can just do target_link_libraries( A) and have it figure out that it needs to link against B as well? Note that neither A nor B are built using cmake, they already exist. ~Roman ___ 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] third party library dependencies
Hi Roman,
Not in a portable way. I'm not too familiar with Windows, but on Linux
you can do this when libA is a shared library that has its dependency on
libB linked in (e.g. ldd libA.so will tell you this). When linking in
static libraries you're out of luck.
I would write a FindA.cmake file for this and let that macro set the
variable A_LIBRARIES to contain both libA and libB. You can then use:
find_package(A)
target_link_libraries(${A_LIBRARIES})
Hope this helps,
Marcel Loose.
On Thu, 2009-12-17 at 12:18 -0500, Roman Shtylman wrote:
> Is there an easy way to setup link dependencies between libraries not
> build using cmake?
>
> Lets say I have a system library A which depends on system library B.
> I then make an executable that uses code from A. I need to link
> against A and B, but as a user of just library A, I don't want to
> worry about that. Does cmake have a facility to define such a
> hierarchy/dependency chain so that I can just do
>
> target_link_libraries( A)
>
> and have it figure out that it needs to link against B as well?
>
> Note that neither A nor B are built using cmake, they already exist.
>
> ~Roman
> ___
> 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] third party library dependencies
On Fri, Dec 18, 2009 at 10:19 AM, Marcel Loose wrote:
> Hi Roman,
>
> Not in a portable way. I'm not too familiar with Windows, but on Linux
> you can do this when libA is a shared library that has its dependency on
> libB linked in (e.g. ldd libA.so will tell you this). When linking in
> static libraries you're out of luck.
>
> I would write a FindA.cmake file for this and let that macro set the
> variable A_LIBRARIES to contain both libA and libB. You can then use:
>
> find_package(A)
> target_link_libraries(${A_LIBRARIES})
>
I've had to deal with this issue and Marcel's proposal is what I do. There
is one slight gotcha that I haven't resolved cleanly yet. Suppose that
A_LIBRARIES depends on certain Boost components, so inside FindA.cmake I
perform a
find_package(Boost REQUIRED COMPONENTS xxx yyy)
and append Boost_LIBRARIES to A_LIBRARIES. Note: I use find_package instead
of hardcoding the library names so that libraries appear as fully qualified
paths, and nonstandard installation paths can be used. Everything OK for
now.
Now, in my project, which depends on A and some other Boost component I do
find_package(A)
find_package(Boost REQUIRED COMPONENTS zzz)
What happens is that since Boost was already found in A, the zzz component
is not included in Boost_LIBRARIES. Has anybody found a successful way of
dealing with this?
TIA,
Adolfo
> Hope this helps,
> Marcel Loose.
>
>
> On Thu, 2009-12-17 at 12:18 -0500, Roman Shtylman wrote:
> > Is there an easy way to setup link dependencies between libraries not
> > build using cmake?
> >
> > Lets say I have a system library A which depends on system library B.
> > I then make an executable that uses code from A. I need to link
> > against A and B, but as a user of just library A, I don't want to
> > worry about that. Does cmake have a facility to define such a
> > hierarchy/dependency chain so that I can just do
> >
> > target_link_libraries( A)
> >
> > and have it figure out that it needs to link against B as well?
> >
> > Note that neither A nor B are built using cmake, they already exist.
> >
> > ~Roman
> > ___
> > 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
>
--
Adolfo Rodríguez Tsouroukdissian, Ph. D.
Robotics engineer
PAL ROBOTICS S.L
http://www.pal-robotics.com
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden
contener información privilegiada y/o confidencial que está dirigida
exclusivamente a su destinatario. Si usted recibe este mensaje y no es el
destinatario indicado, o el empleado encargado de su entrega a dicha
persona, por favor, notifíquelo inmediatamente y remita el mensaje original
a la dirección de correo electrónico indicada. Cualquier copia, uso o
distribución no autorizados de esta comunicación queda estrictamente
prohibida.
CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
contain confidential information which is privileged and intended only for
the individual or entity to whom they are addressed. If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution or use of this e-mail and/or accompanying document(s) is
strictly prohibited. If you have received this e-mail in error, please
immediately notify the sender at the above e-mail address.
___
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] third party library dependencies
Hi Adolfo,
I cannot reproduce the problem you mention. I made the following
CMakeLists.txt file:
cmake_minimum_required(VERSION 2.6)
project(MyBoost)
find_package(Boost REQUIRED COMPONENTS date_time)
message(STATUS "Boost_FOUND=${Boost_FOUND}")
message(STATUS "Boost_LIBRARIES=${Boost_LIBRARIES}")
find_package(Boost REQUIRED COMPONENTS regex)
message(STATUS "Boost_FOUND=${Boost_FOUND}")
message(STATUS "Boost_LIBRARIES=${Boost_LIBRARIES}")
Running cmake (2.6.2) produces:
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Boost version: 1.36.0
-- Found the following Boost libraries:
-- date_time
-- Boost_FOUND=TRUE
-- Boost_LIBRARIES=/usr/lib64/libboost_date_time-mt.so
-- Boost version: 1.36.0
-- Found the following Boost libraries:
-- regex
-- Boost_FOUND=TRUE
--
Boost_LIBRARIES=/usr/lib64/libboost_date_time-mt.so;/usr/lib64/libboost_regex-mt.so
-- Configuring done
-- Generating done
So, in my case boost_regex is nicely added to boost_date_time.
Best regards,
Marcel Loose.
On Fri, 2009-12-18 at 10:48 +0100, Adolfo Rodríguez Tsouroukdissian
wrote:
>
>
> On Fri, Dec 18, 2009 at 10:19 AM, Marcel Loose
> wrote:
> Hi Roman,
>
> Not in a portable way. I'm not too familiar with Windows, but
> on Linux
> you can do this when libA is a shared library that has its
> dependency on
> libB linked in (e.g. ldd libA.so will tell you this). When
> linking in
> static libraries you're out of luck.
>
> I would write a FindA.cmake file for this and let that macro
> set the
> variable A_LIBRARIES to contain both libA and libB. You can
> then use:
>
> find_package(A)
> target_link_libraries(${A_LIBRARIES})
>
> I've had to deal with this issue and Marcel's proposal is what I do.
> There is one slight gotcha that I haven't resolved cleanly yet.
> Suppose that A_LIBRARIES depends on certain Boost components, so
> inside FindA.cmake I perform a
>
> find_package(Boost REQUIRED COMPONENTS xxx yyy)
>
> and append Boost_LIBRARIES to A_LIBRARIES. Note: I use find_package
> instead of hardcoding the library names so that libraries appear as
> fully qualified paths, and nonstandard installation paths can be used.
> Everything OK for now.
>
> Now, in my project, which depends on A and some other Boost component
> I do
>
> find_package(A)
> find_package(Boost REQUIRED COMPONENTS zzz)
>
> What happens is that since Boost was already found in A, the zzz
> component is not included in Boost_LIBRARIES. Has anybody found a
> successful way of dealing with this?
>
> TIA,
>
> Adolfo
>
>
>
>
> Hope this helps,
> Marcel Loose.
>
>
>
> On Thu, 2009-12-17 at 12:18 -0500, Roman Shtylman wrote:
> > Is there an easy way to setup link dependencies between
> libraries not
> > build using cmake?
> >
> > Lets say I have a system library A which depends on system
> library B.
> > I then make an executable that uses code from A. I need to
> link
> > against A and B, but as a user of just library A, I don't
> want to
> > worry about that. Does cmake have a facility to define such
> a
> > hierarchy/dependency chain so that I can just do
> >
> > target_link_libraries( A)
> >
> > and have it figure out that it needs to link against B as
> well?
> >
> > Note that neither A nor B are built using cmake, they
> already exist.
> >
> > ~Roman
> > ___
> > 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] third party library dependencies
On Fri, Dec 18, 2009 at 11:11 AM, Marcel Loose wrote:
> Hi Adolfo,
>
> I cannot reproduce the problem you mention. I made the following
> CMakeLists.txt file:
>
Hmm, I'll perform a check on my side. I noticed the issue quite some time
ago so I might have missed some details in my previous email. Anyway, thanks
for your test. Your output is definitely the expected behavior I want. I'll
report back as soon as I have something.
Adolfo.
> cmake_minimum_required(VERSION 2.6)
> project(MyBoost)
>
> find_package(Boost REQUIRED COMPONENTS date_time)
> message(STATUS "Boost_FOUND=${Boost_FOUND}")
> message(STATUS "Boost_LIBRARIES=${Boost_LIBRARIES}")
>
> find_package(Boost REQUIRED COMPONENTS regex)
> message(STATUS "Boost_FOUND=${Boost_FOUND}")
> message(STATUS "Boost_LIBRARIES=${Boost_LIBRARIES}")
>
> Running cmake (2.6.2) produces:
> -- The C compiler identification is GNU
> -- The CXX compiler identification is GNU
> -- Check for working C compiler: /usr/bin/gcc
> -- Check for working C compiler: /usr/bin/gcc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Boost version: 1.36.0
> -- Found the following Boost libraries:
> -- date_time
> -- Boost_FOUND=TRUE
> -- Boost_LIBRARIES=/usr/lib64/libboost_date_time-mt.so
> -- Boost version: 1.36.0
> -- Found the following Boost libraries:
> -- regex
> -- Boost_FOUND=TRUE
> --
>
> Boost_LIBRARIES=/usr/lib64/libboost_date_time-mt.so;/usr/lib64/libboost_regex-mt.so
> -- Configuring done
> -- Generating done
>
> So, in my case boost_regex is nicely added to boost_date_time.
>
> Best regards,
> Marcel Loose.
>
>
> On Fri, 2009-12-18 at 10:48 +0100, Adolfo Rodríguez Tsouroukdissian
> wrote:
> >
> >
> > On Fri, Dec 18, 2009 at 10:19 AM, Marcel Loose
> > wrote:
> > Hi Roman,
> >
> > Not in a portable way. I'm not too familiar with Windows, but
> > on Linux
> > you can do this when libA is a shared library that has its
> > dependency on
> > libB linked in (e.g. ldd libA.so will tell you this). When
> > linking in
> > static libraries you're out of luck.
> >
> > I would write a FindA.cmake file for this and let that macro
> > set the
> > variable A_LIBRARIES to contain both libA and libB. You can
> > then use:
> >
> > find_package(A)
> > target_link_libraries(${A_LIBRARIES})
> >
> > I've had to deal with this issue and Marcel's proposal is what I do.
> > There is one slight gotcha that I haven't resolved cleanly yet.
> > Suppose that A_LIBRARIES depends on certain Boost components, so
> > inside FindA.cmake I perform a
> >
> > find_package(Boost REQUIRED COMPONENTS xxx yyy)
> >
> > and append Boost_LIBRARIES to A_LIBRARIES. Note: I use find_package
> > instead of hardcoding the library names so that libraries appear as
> > fully qualified paths, and nonstandard installation paths can be used.
> > Everything OK for now.
> >
> > Now, in my project, which depends on A and some other Boost component
> > I do
> >
> > find_package(A)
> > find_package(Boost REQUIRED COMPONENTS zzz)
> >
> > What happens is that since Boost was already found in A, the zzz
> > component is not included in Boost_LIBRARIES. Has anybody found a
> > successful way of dealing with this?
> >
> > TIA,
> >
> > Adolfo
> >
> >
> >
> >
> > Hope this helps,
> > Marcel Loose.
> >
> >
> >
> > On Thu, 2009-12-17 at 12:18 -0500, Roman Shtylman wrote:
> > > Is there an easy way to setup link dependencies between
> > libraries not
> > > build using cmake?
> > >
> > > Lets say I have a system library A which depends on system
> > library B.
> > > I then make an executable that uses code from A. I need to
> > link
> > > against A and B, but as a user of just library A, I don't
> > want to
> > > worry about that. Does cmake have a facility to define such
> > a
> > > hierarchy/dependency chain so that I can just do
> > >
> > > target_link_libraries( A)
> > >
> > > and have it figure out that it needs to link against B as
> > well?
> > >
> > > Note that neither A nor B are built using cmake, they
> > already exist.
> > >
> > > ~Roman
> > > ___
> > > 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:
> >
Re: [CMake] third party library dependencies
On Fri, Dec 18, 2009 at 11:11 AM, Marcel Loose wrote:
> Hi Adolfo,
>
> I cannot reproduce the problem you mention. I made the following
> CMakeLists.txt file:
>
Hmm, I'll perform a check on my side. I noticed the issue quite some time
ago so I might have missed some details in my previous email. Anyway, thanks
for your test. Your output is definitely the expected behavior I want. I'll
report back as soon as I have something.
>
> cmake_minimum_required(VERSION 2.6)
> project(MyBoost)
>
> find_package(Boost REQUIRED COMPONENTS date_time)
> message(STATUS "Boost_FOUND=${Boost_FOUND}")
> message(STATUS "Boost_LIBRARIES=${Boost_LIBRARIES}")
>
> find_package(Boost REQUIRED COMPONENTS regex)
> message(STATUS "Boost_FOUND=${Boost_FOUND}")
> message(STATUS "Boost_LIBRARIES=${Boost_LIBRARIES}")
>
> Running cmake (2.6.2) produces:
> -- The C compiler identification is GNU
> -- The CXX compiler identification is GNU
> -- Check for working C compiler: /usr/bin/gcc
> -- Check for working C compiler: /usr/bin/gcc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Boost version: 1.36.0
> -- Found the following Boost libraries:
> -- date_time
> -- Boost_FOUND=TRUE
> -- Boost_LIBRARIES=/usr/lib64/libboost_date_time-mt.so
> -- Boost version: 1.36.0
> -- Found the following Boost libraries:
> -- regex
> -- Boost_FOUND=TRUE
> --
>
> Boost_LIBRARIES=/usr/lib64/libboost_date_time-mt.so;/usr/lib64/libboost_regex-mt.so
> -- Configuring done
> -- Generating done
>
> So, in my case boost_regex is nicely added to boost_date_time.
>
> Best regards,
> Marcel Loose.
>
>
> On Fri, 2009-12-18 at 10:48 +0100, Adolfo Rodríguez Tsouroukdissian
> wrote:
> >
> >
> > On Fri, Dec 18, 2009 at 10:19 AM, Marcel Loose
> > wrote:
> > Hi Roman,
> >
> > Not in a portable way. I'm not too familiar with Windows, but
> > on Linux
> > you can do this when libA is a shared library that has its
> > dependency on
> > libB linked in (e.g. ldd libA.so will tell you this). When
> > linking in
> > static libraries you're out of luck.
> >
> > I would write a FindA.cmake file for this and let that macro
> > set the
> > variable A_LIBRARIES to contain both libA and libB. You can
> > then use:
> >
> > find_package(A)
> > target_link_libraries(${A_LIBRARIES})
> >
> > I've had to deal with this issue and Marcel's proposal is what I do.
> > There is one slight gotcha that I haven't resolved cleanly yet.
> > Suppose that A_LIBRARIES depends on certain Boost components, so
> > inside FindA.cmake I perform a
> >
> > find_package(Boost REQUIRED COMPONENTS xxx yyy)
> >
> > and append Boost_LIBRARIES to A_LIBRARIES. Note: I use find_package
> > instead of hardcoding the library names so that libraries appear as
> > fully qualified paths, and nonstandard installation paths can be used.
> > Everything OK for now.
> >
> > Now, in my project, which depends on A and some other Boost component
> > I do
> >
> > find_package(A)
> > find_package(Boost REQUIRED COMPONENTS zzz)
> >
> > What happens is that since Boost was already found in A, the zzz
> > component is not included in Boost_LIBRARIES. Has anybody found a
> > successful way of dealing with this?
> >
> > TIA,
> >
> > Adolfo
> >
> >
> >
> >
> > Hope this helps,
> > Marcel Loose.
> >
> >
> >
> > On Thu, 2009-12-17 at 12:18 -0500, Roman Shtylman wrote:
> > > Is there an easy way to setup link dependencies between
> > libraries not
> > > build using cmake?
> > >
> > > Lets say I have a system library A which depends on system
> > library B.
> > > I then make an executable that uses code from A. I need to
> > link
> > > against A and B, but as a user of just library A, I don't
> > want to
> > > worry about that. Does cmake have a facility to define such
> > a
> > > hierarchy/dependency chain so that I can just do
> > >
> > > target_link_libraries( A)
> > >
> > > and have it figure out that it needs to link against B as
> > well?
> > >
> > > Note that neither A nor B are built using cmake, they
> > already exist.
> > >
> > > ~Roman
> > > ___
> > > 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:
> > > ht
Re: [CMake] third party library dependencies
On Fri, 18 Dec 2009 10:19:05 +0100, "Marcel Loose" wrote: > Hi Roman, > > Not in a portable way. I'm not too familiar with Windows, but on Linux > you can do this when libA is a shared library that has its dependency on > libB linked in (e.g. ldd libA.so will tell you this). When linking in > static libraries you're out of luck. With shared libraries, you need not and *should not* explicitly link recursive dependencies. If you have both static and shared libraries, the output of ldd could be used to find the recursive deps needed to link statically. This sucks and the logic to determine whether to put recursive deps in FOO_LIBRARIES ends up going in FindFoo.cmake which is insane. FWIW, pkg-config has Libs.private for this purpose. Finally, it would be nice to easily associate a symbol with a call to find_library. That is, suppose libA links to libB and libC, but libA never exposes libB or libC to users. To do the right thing (without abusing ldd), FindA.cmake needs to try linking with just -lA (which will work with all shared libs), then try with -lA -lB and -lA -lC before falling back to -lA -lB -lC (which is required when all libs are static). A better way which does not have exponential complexity would be to declare that the symbol "B_Foo" belongs with a libB and "C_Bar" belongs with a libC. So when linking with -lA fails, libB would be added exactly when B_Foo is undefined. Jed ___ 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] third party library dependencies
In my setup I have statically linked libraries, thus the library dependencies are not automatically pulled in. I suppose I can do some things with ldd to determine which libraries are needed. Initially, to make things simple, if libA used libB and libC (all statically linked) then when linking an executable against libA I will want to also link against libB and C. On Fri, Dec 18, 2009 at 11:54 AM, Jed Brown wrote: > On Fri, 18 Dec 2009 10:19:05 +0100, "Marcel Loose" wrote: >> Hi Roman, >> >> Not in a portable way. I'm not too familiar with Windows, but on Linux >> you can do this when libA is a shared library that has its dependency on >> libB linked in (e.g. ldd libA.so will tell you this). When linking in >> static libraries you're out of luck. > > With shared libraries, you need not and *should not* explicitly link > recursive dependencies. If you have both static and shared libraries, > the output of ldd could be used to find the recursive deps needed to > link statically. This sucks and the logic to determine whether to put > recursive deps in FOO_LIBRARIES ends up going in FindFoo.cmake which is > insane. FWIW, pkg-config has Libs.private for this purpose. > > Finally, it would be nice to easily associate a symbol with a call to > find_library. That is, suppose libA links to libB and libC, but libA > never exposes libB or libC to users. To do the right thing (without > abusing ldd), FindA.cmake needs to try linking with just -lA (which will > work with all shared libs), then try with -lA -lB and -lA -lC before > falling back to -lA -lB -lC (which is required when all libs are > static). A better way which does not have exponential complexity would > be to declare that the symbol "B_Foo" belongs with a libB and "C_Bar" > belongs with a libC. So when linking with -lA fails, libB would be > added exactly when B_Foo is undefined. > > Jed > ___ 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] third party library dependencies
Realistically, what I want to create is something that allows me to define a dependency chain for static libraries so that the final executable developer does not need to worry about the dependencies. I should be able to abstract this away into a module. On Fri, Dec 18, 2009 at 2:45 PM, Roman Shtylman wrote: > In my setup I have statically linked libraries, thus the library > dependencies are not automatically pulled in. I suppose I can do some > things with ldd to determine which libraries are needed. Initially, to > make things simple, if libA used libB and libC (all statically linked) > then when linking an executable against libA I will want to also link > against libB and C. > > On Fri, Dec 18, 2009 at 11:54 AM, Jed Brown wrote: >> On Fri, 18 Dec 2009 10:19:05 +0100, "Marcel Loose" wrote: >>> Hi Roman, >>> >>> Not in a portable way. I'm not too familiar with Windows, but on Linux >>> you can do this when libA is a shared library that has its dependency on >>> libB linked in (e.g. ldd libA.so will tell you this). When linking in >>> static libraries you're out of luck. >> >> With shared libraries, you need not and *should not* explicitly link >> recursive dependencies. If you have both static and shared libraries, >> the output of ldd could be used to find the recursive deps needed to >> link statically. This sucks and the logic to determine whether to put >> recursive deps in FOO_LIBRARIES ends up going in FindFoo.cmake which is >> insane. FWIW, pkg-config has Libs.private for this purpose. >> >> Finally, it would be nice to easily associate a symbol with a call to >> find_library. That is, suppose libA links to libB and libC, but libA >> never exposes libB or libC to users. To do the right thing (without >> abusing ldd), FindA.cmake needs to try linking with just -lA (which will >> work with all shared libs), then try with -lA -lB and -lA -lC before >> falling back to -lA -lB -lC (which is required when all libs are >> static). A better way which does not have exponential complexity would >> be to declare that the symbol "B_Foo" belongs with a libB and "C_Bar" >> belongs with a libC. So when linking with -lA fails, libB would be >> added exactly when B_Foo is undefined. >> >> Jed >> > ___ 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] third party library dependencies
On Fri, 18 Dec 2009 14:45:51 -0500, Roman Shtylman wrote: > In my setup I have statically linked libraries, thus the library > dependencies are not automatically pulled in. I suppose I can do some > things with ldd to determine which libraries are needed. Yes, but ldd will only help if your system also has shared versions of these libraries. If you only have statically linked versions, then the presence of unresolved symbols are the only indication that a recursive dependency is missing (in the absence of pkgconfig or other external indicator). > Initially, to make things simple, if libA used libB and libC (all > statically linked) then when linking an executable against libA I will > want to also link against libB and C. Yes, with static linking, all recursive deps should go into a FOO_LIBRARIES. Yes, it's a PITA to work out what the recursive deps are, and CMake currently doesn't help. Also, static linking should not be a global choice made in some Find*.cmake. This appears to be a major flaw, the vast majority of Find* modules distributed with CMake are broken for static linking. I've pointed it out before and the response seems to be that either you shouldn't want to do such a thing or that Find* authors should write clairvoyant code. Jed ___ 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] third party library dependencies
2009/12/18 Adolfo Rodríguez Tsouroukdissian <
adolfo.rodrig...@pal-robotics.com>
>
>
> On Fri, Dec 18, 2009 at 11:11 AM, Marcel Loose wrote:
>
>> Hi Adolfo,
>>
>> I cannot reproduce the problem you mention. I made the following
>> CMakeLists.txt file:
>>
> Hmm, I'll perform a check on my side. I noticed the issue quite some time
> ago so I might have missed some details in my previous email. Anyway, thanks
> for your test. Your output is definitely the expected behavior I want. I'll
> report back as soon as I have something.
>
OK. I have reproduced the issue. It appears that it may be specific to
FindBoost.cmake, I'm posting the details in a new thread, since it woud be
OT here...
>
>> cmake_minimum_required(VERSION 2.6)
>> project(MyBoost)
>>
>> find_package(Boost REQUIRED COMPONENTS date_time)
>> message(STATUS "Boost_FOUND=${Boost_FOUND}")
>> message(STATUS "Boost_LIBRARIES=${Boost_LIBRARIES}")
>>
>> find_package(Boost REQUIRED COMPONENTS regex)
>> message(STATUS "Boost_FOUND=${Boost_FOUND}")
>> message(STATUS "Boost_LIBRARIES=${Boost_LIBRARIES}")
>>
>> Running cmake (2.6.2) produces:
>> -- The C compiler identification is GNU
>> -- The CXX compiler identification is GNU
>> -- Check for working C compiler: /usr/bin/gcc
>> -- Check for working C compiler: /usr/bin/gcc -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Check for working CXX compiler: /usr/bin/c++
>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Boost version: 1.36.0
>> -- Found the following Boost libraries:
>> -- date_time
>> -- Boost_FOUND=TRUE
>> -- Boost_LIBRARIES=/usr/lib64/libboost_date_time-mt.so
>> -- Boost version: 1.36.0
>> -- Found the following Boost libraries:
>> -- regex
>> -- Boost_FOUND=TRUE
>> --
>>
>> Boost_LIBRARIES=/usr/lib64/libboost_date_time-mt.so;/usr/lib64/libboost_regex-mt.so
>> -- Configuring done
>> -- Generating done
>>
>> So, in my case boost_regex is nicely added to boost_date_time.
>>
>> Best regards,
>> Marcel Loose.
>>
>>
>> On Fri, 2009-12-18 at 10:48 +0100, Adolfo Rodríguez Tsouroukdissian
>> wrote:
>> >
>> >
>> > On Fri, Dec 18, 2009 at 10:19 AM, Marcel Loose
>> > wrote:
>> > Hi Roman,
>> >
>> > Not in a portable way. I'm not too familiar with Windows, but
>> > on Linux
>> > you can do this when libA is a shared library that has its
>> > dependency on
>> > libB linked in (e.g. ldd libA.so will tell you this). When
>> > linking in
>> > static libraries you're out of luck.
>> >
>> > I would write a FindA.cmake file for this and let that macro
>> > set the
>> > variable A_LIBRARIES to contain both libA and libB. You can
>> > then use:
>> >
>> > find_package(A)
>> > target_link_libraries(${A_LIBRARIES})
>> >
>> > I've had to deal with this issue and Marcel's proposal is what I do.
>> > There is one slight gotcha that I haven't resolved cleanly yet.
>> > Suppose that A_LIBRARIES depends on certain Boost components, so
>> > inside FindA.cmake I perform a
>> >
>> > find_package(Boost REQUIRED COMPONENTS xxx yyy)
>> >
>> > and append Boost_LIBRARIES to A_LIBRARIES. Note: I use find_package
>> > instead of hardcoding the library names so that libraries appear as
>> > fully qualified paths, and nonstandard installation paths can be used.
>> > Everything OK for now.
>> >
>> > Now, in my project, which depends on A and some other Boost component
>> > I do
>> >
>> > find_package(A)
>> > find_package(Boost REQUIRED COMPONENTS zzz)
>> >
>> > What happens is that since Boost was already found in A, the zzz
>> > component is not included in Boost_LIBRARIES. Has anybody found a
>> > successful way of dealing with this?
>> >
>> > TIA,
>> >
>> > Adolfo
>> >
>> >
>> >
>> >
>> > Hope this helps,
>> > Marcel Loose.
>> >
>> >
>> >
>> > On Thu, 2009-12-17 at 12:18 -0500, Roman Shtylman wrote:
>> > > Is there an easy way to setup link dependencies between
>> > libraries not
>> > > build using cmake?
>> > >
>> > > Lets say I have a system library A which depends on system
>> > library B.
>> > > I then make an executable that uses code from A. I need to
>> > link
>> > > against A and B, but as a user of just library A, I don't
>> > want to
>> > > worry about that. Does cmake have a facility to define such
>> > a
>> > > hierarchy/dependency chain so that I can just do
>> > >
>> > > target_link_libraries( A)
>> > >
>> > > and have it figure out that it needs to link against B as
>> > well?
>> > >
>> > > Note that neither A nor B are built using cmake, they
>> > already exist.
>> > >
>> > > ~Roman
>> > > ___
>> >
Re: [CMake] third party library dependencies
On Fri, 2009-12-18 at 08:54 -0800, Jed Brown wrote: > On Fri, 18 Dec 2009 10:19:05 +0100, "Marcel Loose" wrote: > > Hi Roman, > > > > Not in a portable way. I'm not too familiar with Windows, but on Linux > > you can do this when libA is a shared library that has its dependency on > > libB linked in (e.g. ldd libA.so will tell you this). When linking in > > static libraries you're out of luck. > > With shared libraries, you need not and *should not* explicitly link > recursive dependencies. If you have both static and shared libraries, > the output of ldd could be used to find the recursive deps needed to > link statically. This sucks and the logic to determine whether to put > recursive deps in FOO_LIBRARIES ends up going in FindFoo.cmake which is > insane. FWIW, pkg-config has Libs.private for this purpose. > > Finally, it would be nice to easily associate a symbol with a call to > find_library. That is, suppose libA links to libB and libC, but libA > never exposes libB or libC to users. To do the right thing (without > abusing ldd), FindA.cmake needs to try linking with just -lA (which will > work with all shared libs), then try with -lA -lB and -lA -lC before > falling back to -lA -lB -lC (which is required when all libs are > static). A better way which does not have exponential complexity would > be to declare that the symbol "B_Foo" belongs with a libB and "C_Bar" > belongs with a libC. So when linking with -lA fails, libB would be > added exactly when B_Foo is undefined. > > Jed Hi Jed, Why do you consider explicit linking of recursive dependencies a bad thing? It's superfluous, I agree, but there's no harm in it, right? Best regards, Marcel Loose. ___ 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] third party library dependencies
On 21. Dec, 2009, at 12:17 , Marcel Loose wrote: > On Fri, 2009-12-18 at 08:54 -0800, Jed Brown wrote: >> On Fri, 18 Dec 2009 10:19:05 +0100, "Marcel Loose" wrote: >>> Hi Roman, >>> >>> Not in a portable way. I'm not too familiar with Windows, but on Linux >>> you can do this when libA is a shared library that has its dependency on >>> libB linked in (e.g. ldd libA.so will tell you this). When linking in >>> static libraries you're out of luck. >> >> With shared libraries, you need not and *should not* explicitly link >> recursive dependencies. If you have both static and shared libraries, >> the output of ldd could be used to find the recursive deps needed to >> link statically. This sucks and the logic to determine whether to put >> recursive deps in FOO_LIBRARIES ends up going in FindFoo.cmake which is >> insane. FWIW, pkg-config has Libs.private for this purpose. >> >> Finally, it would be nice to easily associate a symbol with a call to >> find_library. That is, suppose libA links to libB and libC, but libA >> never exposes libB or libC to users. To do the right thing (without >> abusing ldd), FindA.cmake needs to try linking with just -lA (which will >> work with all shared libs), then try with -lA -lB and -lA -lC before >> falling back to -lA -lB -lC (which is required when all libs are >> static). A better way which does not have exponential complexity would >> be to declare that the symbol "B_Foo" belongs with a libB and "C_Bar" >> belongs with a libC. So when linking with -lA fails, libB would be >> added exactly when B_Foo is undefined. >> >> Jed > > Hi Jed, > > Why do you consider explicit linking of recursive dependencies a bad > thing? It's superfluous, I agree, but there's no harm in it, right? > > Best regards, > Marcel Loose. > It's called overlinking and can be a real problem for package maintainers. See e.g. here for an explanation: http://wiki.mandriva.com/en/Overlinking 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] third party library dependencies
On Mon, 2009-12-21 at 13:32 +0100, Michael Wild wrote: > On 21. Dec, 2009, at 12:17 , Marcel Loose wrote: > > > On Fri, 2009-12-18 at 08:54 -0800, Jed Brown wrote: > >> On Fri, 18 Dec 2009 10:19:05 +0100, "Marcel Loose" wrote: > >>> Hi Roman, > >>> > >>> Not in a portable way. I'm not too familiar with Windows, but on Linux > >>> you can do this when libA is a shared library that has its dependency on > >>> libB linked in (e.g. ldd libA.so will tell you this). When linking in > >>> static libraries you're out of luck. > >> > >> With shared libraries, you need not and *should not* explicitly link > >> recursive dependencies. If you have both static and shared libraries, > >> the output of ldd could be used to find the recursive deps needed to > >> link statically. This sucks and the logic to determine whether to put > >> recursive deps in FOO_LIBRARIES ends up going in FindFoo.cmake which is > >> insane. FWIW, pkg-config has Libs.private for this purpose. > >> > >> Finally, it would be nice to easily associate a symbol with a call to > >> find_library. That is, suppose libA links to libB and libC, but libA > >> never exposes libB or libC to users. To do the right thing (without > >> abusing ldd), FindA.cmake needs to try linking with just -lA (which will > >> work with all shared libs), then try with -lA -lB and -lA -lC before > >> falling back to -lA -lB -lC (which is required when all libs are > >> static). A better way which does not have exponential complexity would > >> be to declare that the symbol "B_Foo" belongs with a libB and "C_Bar" > >> belongs with a libC. So when linking with -lA fails, libB would be > >> added exactly when B_Foo is undefined. > >> > >> Jed > > > > Hi Jed, > > > > Why do you consider explicit linking of recursive dependencies a bad > > thing? It's superfluous, I agree, but there's no harm in it, right? > > > > Best regards, > > Marcel Loose. > > > > It's called overlinking and can be a real problem for package maintainers. > See e.g. here for an explanation: http://wiki.mandriva.com/en/Overlinking > > Michael > OK, I see. This raises another question, which was already alluded to in this thread, and may have been asked before on this list: Is there a way to write FindXXX.cmake macros in such a way that they will always return the correct list of libraries to link against? I.e., a short list of direct dependencies when linking against shared libraries, and a long complete list of recursive dependencies when linking against static libraries. Best regards, Marcel Loose. ___ 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] third party library dependencies
On 21. Dec, 2009, at 14:16 , Marcel Loose wrote: > On Mon, 2009-12-21 at 13:32 +0100, Michael Wild wrote: >> On 21. Dec, 2009, at 12:17 , Marcel Loose wrote: >> >>> On Fri, 2009-12-18 at 08:54 -0800, Jed Brown wrote: On Fri, 18 Dec 2009 10:19:05 +0100, "Marcel Loose" wrote: > Hi Roman, > > Not in a portable way. I'm not too familiar with Windows, but on Linux > you can do this when libA is a shared library that has its dependency on > libB linked in (e.g. ldd libA.so will tell you this). When linking in > static libraries you're out of luck. With shared libraries, you need not and *should not* explicitly link recursive dependencies. If you have both static and shared libraries, the output of ldd could be used to find the recursive deps needed to link statically. This sucks and the logic to determine whether to put recursive deps in FOO_LIBRARIES ends up going in FindFoo.cmake which is insane. FWIW, pkg-config has Libs.private for this purpose. Finally, it would be nice to easily associate a symbol with a call to find_library. That is, suppose libA links to libB and libC, but libA never exposes libB or libC to users. To do the right thing (without abusing ldd), FindA.cmake needs to try linking with just -lA (which will work with all shared libs), then try with -lA -lB and -lA -lC before falling back to -lA -lB -lC (which is required when all libs are static). A better way which does not have exponential complexity would be to declare that the symbol "B_Foo" belongs with a libB and "C_Bar" belongs with a libC. So when linking with -lA fails, libB would be added exactly when B_Foo is undefined. Jed >>> >>> Hi Jed, >>> >>> Why do you consider explicit linking of recursive dependencies a bad >>> thing? It's superfluous, I agree, but there's no harm in it, right? >>> >>> Best regards, >>> Marcel Loose. >>> >> >> It's called overlinking and can be a real problem for package maintainers. >> See e.g. here for an explanation: http://wiki.mandriva.com/en/Overlinking >> >> Michael >> > > OK, I see. > > This raises another question, which was already alluded to in this > thread, and may have been asked before on this list: > > Is there a way to write FindXXX.cmake macros in such a way that they > will always return the correct list of libraries to link against? I.e., > a short list of direct dependencies when linking against shared > libraries, and a long complete list of recursive dependencies when > linking against static libraries. > > Best regards, > Marcel Loose. I honestly don't know. I wouldn't even know how to reliably differentiate between static and dynamic libraries. AFAIK some platforms use the same naming scheme, e.g. Windows uses .lib for both, static libraries and import libraries. AIX distinguishes between shared objects (really, only an object file with shared code) and shared libraries. The former either uses .o or .so (who had THIS great idea), while shared libraries use .a as do static libraries. Very confusing: http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=/com.ibm.vacpp7a.doc/getstart/overview/port_aix_obj_lib.htm Perhaps we need some new IF(STATIC_LIBRARY ) command? But then that would probably require a database with file detection magic (such as Unix file(1) command uses) 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] third party library dependencies
On Mon, 2009-12-21 at 14:43 +0100, Michael Wild wrote: > On 21. Dec, 2009, at 14:16 , Marcel Loose wrote: > > > On Mon, 2009-12-21 at 13:32 +0100, Michael Wild wrote: > >> On 21. Dec, 2009, at 12:17 , Marcel Loose wrote: > >> > >>> On Fri, 2009-12-18 at 08:54 -0800, Jed Brown wrote: > On Fri, 18 Dec 2009 10:19:05 +0100, "Marcel Loose" > wrote: > > Hi Roman, > > > > Not in a portable way. I'm not too familiar with Windows, but on Linux > > you can do this when libA is a shared library that has its dependency on > > libB linked in (e.g. ldd libA.so will tell you this). When linking in > > static libraries you're out of luck. > > With shared libraries, you need not and *should not* explicitly link > recursive dependencies. If you have both static and shared libraries, > the output of ldd could be used to find the recursive deps needed to > link statically. This sucks and the logic to determine whether to put > recursive deps in FOO_LIBRARIES ends up going in FindFoo.cmake which is > insane. FWIW, pkg-config has Libs.private for this purpose. > > Finally, it would be nice to easily associate a symbol with a call to > find_library. That is, suppose libA links to libB and libC, but libA > never exposes libB or libC to users. To do the right thing (without > abusing ldd), FindA.cmake needs to try linking with just -lA (which will > work with all shared libs), then try with -lA -lB and -lA -lC before > falling back to -lA -lB -lC (which is required when all libs are > static). A better way which does not have exponential complexity would > be to declare that the symbol "B_Foo" belongs with a libB and "C_Bar" > belongs with a libC. So when linking with -lA fails, libB would be > added exactly when B_Foo is undefined. > > Jed > >>> > >>> Hi Jed, > >>> > >>> Why do you consider explicit linking of recursive dependencies a bad > >>> thing? It's superfluous, I agree, but there's no harm in it, right? > >>> > >>> Best regards, > >>> Marcel Loose. > >>> > >> > >> It's called overlinking and can be a real problem for package maintainers. > >> See e.g. here for an explanation: http://wiki.mandriva.com/en/Overlinking > >> > >> Michael > >> > > > > OK, I see. > > > > This raises another question, which was already alluded to in this > > thread, and may have been asked before on this list: > > > > Is there a way to write FindXXX.cmake macros in such a way that they > > will always return the correct list of libraries to link against? I.e., > > a short list of direct dependencies when linking against shared > > libraries, and a long complete list of recursive dependencies when > > linking against static libraries. > > > > Best regards, > > Marcel Loose. > > I honestly don't know. I wouldn't even know how to reliably differentiate > between static and dynamic libraries. AFAIK some platforms use the same > naming scheme, e.g. Windows uses .lib for both, static libraries and import > libraries. AIX distinguishes between shared objects (really, only an object > file with shared code) and shared libraries. The former either uses .o or .so > (who had THIS great idea), while shared libraries use .a as do static > libraries. Very confusing: > http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=/com.ibm.vacpp7a.doc/getstart/overview/port_aix_obj_lib.htm > > Perhaps we need some new IF(STATIC_LIBRARY ) command? But then that > would probably require a database with file detection magic (such as Unix > file(1) command uses) > > Michael Hi Michael, and others, Upon (re)reading the Mandriva page you were referring to, I was thinking: maybe this issue can be solved more or less the same way as pkg-config does: i.e. by defining private dependencies. This could be an extra option to target_link_libraries. Something like: target_link_libraries(mylib public1 public2 PRIVATE private1 private2) This would tell CMake that mylib directly depends on public1 and public2 and should *only* link in these two libraries when these are shared object libraries; otherwise private1 and private2 would also need to be added on the link line. The big hurdle to take, of course, is to detect in a platform-independent way whether the given library is shared or static. However, a lot of this knowledge is already available in the diverse Modules/Platform macros, so my feeling is that this should be feasible. Best regards, Marcel Loose. ___ 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
