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 <[email protected]>: > 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 <[email protected]>: >> 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 <[email protected]>: >>> 2011/4/23 Rosen Diankov <[email protected]>: >>>> 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 >>> >> > _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
