[CMake] Better handling of library dependencies for CPack

[Rosen Diankov]

Perhaps it would be better to have support for

set(X_DEPENDS_${DISTRO} gcc4.4)

If this is missing, the dependencies will fall back to the regular
X_DEPENDS variable

rosen,

2011/4/23 Rosen Diankov <rosen.diankov at gmail.com>:
> 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
>>
>