I'm getting ready to build this afternoon. Where are we at for CMake? Questions are ...
1. Does CMake determine the min dependency, and can evaluate and confirm the correct one without hardsetting version numbers for the dependencies? 2. Can -DCPACK ... RPM=on be turned off by default? This would alleviate a lot of cruft from the build instructions 3. While I'm only concerned about Ubuntu, because it is a *.deb package, are debain requirements being set up correctly? 4. How do these changes affect other distro packaging systems, such as RPM, etc. Dale On Mon, 2010-09-13 at 08:25 +0200, Kornel Benko wrote: > 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 -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
