[CMake] Better handling of library dependencies for CPack

Eric Noulard eric.noulard at gmail.com
Fri Apr 22 06:02:11 EDT 2011


2011/4/22 Rosen Diankov <rosen.diankov at gmail.com>:
> Hi all,
>
> We've recently started generating (debian) packages with CPack and
> discovered that handling library dependencies for particular
> distributions was not as smooth as it can be. The *_DEPENDS string
> just gets copied over to the final package so it puts all the burden
> on the user side to manage what distribution's dependencies get
> enabled.


For Deb package did you try the
CPACK_DEBIAN_PACKAGE_SHLIBDEPS ?

set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)
will make CPackDeb use dpkg-shlibdeps in order to find lib dependencies.

> Instead, can we have something similar to how build-type-dependent
> libraries work out? For example, a library string can be set according
> to:
>
> set(LIBRARY debug mylibraryd optimized mylibrary)
>
> And joining multiple library strings will take care of organizing the
> dependencies. In the same way, it would be cool if we can specify
> distribution dependencies that way:
>
> set(*DEPENDS ubuntu mylib3-dev debian mylib-devel)
>
> Then depending on the distribution type the user sets, the correct
> dependencies can be selected.

You can already do "Generator"  specific dependencies using a CPack
project config file
see:
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29

This file is evaluated at cpack time, if you do match the distro name then you
can already select the specific dependency yourself.

An example on how to match distro name with "lsb_release" command or
"/etc/issue" file
is given in the attached script.


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SystemSpecificInformations.cmake
Type: application/octet-stream
Size: 6771 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110422/232cd450/attachment.obj>


More information about the CMake mailing list