[CMake] Better handling of library dependencies for CPack

[Rosen Diankov]

After thinking about it, perhaps it would make most sense to have
DISTRO be ubuntu, debian, fedora, etc, rather than the code name.
rosen,

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