[CMake] Better handling of library dependencies for CPack

Eric Noulard eric.noulard at gmail.com
Fri Apr 22 18:23:38 EDT 2011


2011/4/22 Rosen Diankov <rosen.diankov at gmail.com>:
> Hi Eric,
>
> Before I start running things, basically the script sets
> CPACK_DEBIAN_PACKAGE_DEPENDS right? What does this effect have on
> cpack?

On CPack generic part none but the CPack Debian generator use it
when building the binary debian package and adds the packages
mentionned  in  CPACK_DEBIAN_PACKAGE_DEPENDS as dependencies.

But I thougt you were already doing this, am I wrong?

> Also, If we're generating debian source packages, i'm not sure if it
> is a good idea to set DISTRO_CODENAME, DISTRO_RELEASE, AND DISTRO_ID
> inside the cmake environment. Ideally it should be possible to
> generate the source packages for all distributions on the same OS.

Yes it should source packages tends to have less distro-specific dependencies.
The example of definition of DISTRO_CODENAME, DISTRO_RELEASE etc...
is just an example you could just define the var which is useful for your
"do distro specific things at CPack time".

Currently I do source distribution using compressed tarball and use
give some instruction on how to build RPM, Deb etc.. out of that
so that I don't need source deb or source rpm.

> I guess this is where the philosophical arguments would start: is it
> really necessary for cmake/cpack to generate source debs for a
> different distribution than the one it is currently running on ;0)

Cross-packaging is even more tedious than cross-compiling.
If I had to that I think I will go with virtual machine hosting the
target system,
but as you said it's a philosophical point of view.

> i would say yes. Even if it is possible to set up chroot environments
> for N OSes, the sourcecode files would have to be sent N times,
> whereas they only need to be sent once...
>
> Also, you can do
>
> lsb_release -is
> lsb_release -rs
> lsb_release -cs
>
> to get the names directly without regex.

Yes thanks I'll update my script.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org


More information about the CMake mailing list