Am Sonntag, 12. September 2010 schrieb Yuval Levy: > On September 11, 2010 06:04:34 pm Kornel Benko wrote: > > Am Samstag 11 September 2010 schrieb Yuval Levy: > > > On September 9, 2010 06:29:31 pm Kornel Benko wrote: > > > > It should be (at a proper place) > > > > > > > > set(CPACK_DEBIAN_PACKAGE_DEPENDS "libpost2c2, libglew1.5, > > > > freeglut3, > > > > > > > > libboost-filesystem1.40.0, liblcms1, libopenexr6, libtiff4") but before > > > > the line) > > > > > > > > INCLUDE(CPack) > > > > > > done! I neded a changeset to test tweaking to the email notifications > > > from the repo. > > > > Hmmm, it was meant only as a correction of syntax for a proposal from Dale. > > I did not want to say, the values are correct :( > > > > So for instance for me it is libboost-filesystem1.38.0 and not > > libboost-filesystem1.40.0. This depends on the build-system unfortunately. > > fixed. there is a syntax for version numbers. Refernce [0]
OK > I have the impression that our CMake build is still incomplete and maybe > Andreas want to chime in with his expertise? :) > * right now we do not set CPACK_DEBIAN_PACKAGE_ARCHITECTURE - how are 32bit > packages distinguished form 64bit packages? should we set > CPACK_DEBIAN_PACKAGE_ARCHITECTURE, and if yes how? I would say not needed, but we could name the package accordingly. ( CPACK_DEBIAN_PACKAGE_ARCHITECTURE is set automatically through "dpkg --print-architecture") > * for the dependencies it seems to be on CMake's TODO list to automate > 'objdump -p | grep NEEDED' - can this be scripted / integrated in our CMake > build? Yes, we could. I fear, the list would be somehow lengthy this way. Is this script already available somewhere? > * we do not set the maintainer, which is Debian-mandatory. > CPACK_DEBIAN_PACKAGE_MAINTAINER We do, in setting CPACK_PACKAGE_CONTACT > * we do not set the description, which is Debian-mandatory too. > CPACK_DEBIAN_PACKAGE_DESCRIPTION - what does the description say in your > official packages, Andreas? maybe we should copy it rather than reinvent the > wheel? We should set CPACK_PACKAGE_DESCRIPTION_SUMMARY > * what can/should we do with the recommended fields (section / priority / > recommends / suggests / control extra) ? I would say, it's ok as it is. > * Anything else I am missing on the way to a proper Debian package out of > CMake? I had no problems with our package, neither with rpm nor with debian packaging, so I don't see the missings ... > Yuv > > [0] > http://www.paraview.org/Wiki/CMake:CPackPackageGenerators#DEB_.28UNIX_only.29 > kornel
signature.asc
Description: This is a digitally signed message part.
