[CMake] Better handling of library dependencies for CPack

[Rosen Diankov]

Hi Eric,

Great, I'm all for the idea of helping add DebSourcePPA.cmake to the
official cmake modules list. Because there's overlap with
CPackDeb.cmake, perhaps there is some way to merge the functionality?

I would still like to resolve the dependencies setting this email
initially started with. In other words:

if( CODENAME == lucid )
 set(DEPENDS)
elseif( CODENAME == maverick )
 set(DEPENDS)
endif()

will not work that great for debian source packages since every piece
of code setting dependencies would need such constructions, and it
means you cannot create multiple source packages targetted for
different distros at once. As we discussed in a previous email, this
allows us to send only one source file.

Instead it would be great to have:

set(DEPENDS gcc lucid "gcc4.4" karmic "gcc4.3")

where 'gcc' is used for any distros that are not lucid or karmic.

being able to integrate such depends in DebSourcePPA.cmake would be
very cool and shouldn't take that much programming time for a cmake
dev ;0)

thank you,
rosen,

2011/4/23 Eric Noulard <eric.noulard at gmail.com>:
> 2011/4/23 Rosen Diankov <rosen.diankov at gmail.com>:
>> Hi Eric,
>>
>> Thanks for the response. In another email to cmake.org, I sent a
>> DebSourcePPA.cmake file that shows what i'm doing to generate deb
>> source packages.
>
> Yes I saw that one, this is interesting, may be it could go upstream,
> if you want it to go upstream please file a bug report and attach
> your most up to date script to the tracker.
>
> We can see if it should be handled as a sort of independent Module
> http://www.itk.org/Wiki/CMake:Module_Maintainers
> or as a new CPack source generator.
>
>> Your script sets CPACK_DEBIAN_PACKAGE_DEPENDS to "Ubuntu-dep", so I
>> was confused how that adds the correct dependencies... what does a
>> user have to set?
>
> Sorry about that my example was only for explaining how to do different
> things **at cpack time** depending on the distribution ID.
> "Ubuntu-dep" is a dummy placeholder.
>
> A useful value should be the usual list of deps you'll find in after:
>
> "Depends:"
>
> is a DSC file, e.g. for "Depends: libc6 (>= 2.1)"
> you can do:
> set(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.1)")
>
>
> Note that you can also specify "Pre-Depends:" using
> CPACK_DEBIAN_PACKAGE_PREDEPENDS
>
> Have a look at:
>
> cmake --help-module CPackDeb
>
> you should get an hopefully complete list of var handled by CPackDeb.
> If the documentation
> (found in CPackDeb.cmake)
> is not complete do not hesitate to file a patch.
>
>
>> I understand that using cpack to create a tar ball for the
>> installables in each component is a working option, the dependencies
>> can then be added as we talked. However, launchpad (the official build
>> farm for ubuntu) does not accept binary deb packages, this means we
>> have to send a deb source that builds on their servers for all the
>> distributions we support. I think fedora core also asks for the source
>> rpms. This is why we went through the trouble of using
>> DebSourcePPA.cmake when there are many other options available.
>
> This is a very valuable effort.
> The trouble with "source packages" be it deb or rpm is that it has some
> overlappinh feature with CPack. However as you said if since some
> project request it
> we should find a way to build deb (or rpm) src.
>
> Try to seek the mailing list archive concerning "source package" with
> CPack and you
> will find pro- and cons- the idea.
>
> May be we should re-discuss this in the light of your current remarks.
>
> --
> Erk
> Membre de l'April - « promouvoir et défendre le logiciel libre » -
> http://www.april.org
>