Earlier I had indicated using echo from a script to read in the dependencies. Someone mentioned that this would not work? Is this because of the location of the line in the CMakeLists.txt?
I'd have to dig around for the e-mail, but someone indicated that -DCPACK_BINARY_DEB:BOOL=off/on could be set by default within the CMakeLists.txt file and then we'd only need to issue the line for the particular type of build we were doing, rather than a long list of BOOL=off libboost-filesystem (& -system) is indicated as optional, but issues errors about boost filesystem all the way through the build and afterwards during program use about boost not being found. is (filesystem & system) truly optional, and if so, is there a way to squelch the error and confirm that the build is in fact finding boost? Dale On Mon, 2010-09-13 at 18:36 +0200, Kornel Benko wrote: > Am Montag 13 September 2010 schrieb Dale Beams: > > 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? > > No > > > 2. Can -DCPACK ... RPM=on be turned off by default? This would > > alleviate a lot of cruft from the build instructions > > If we could automatically determine the package management of the build > system, then yes. > It should not be that difficult though. On the other side, cmake itself > should give us the info ... > > > 3. While I'm only concerned about Ubuntu, because it is a *.deb package, > > are debain requirements being set up correctly? > > No. The requirements depend on the build-system, so they cannot be hardcoded. > It's always possible to have them wrong. > I could prepare something for ubuntu 10.4 64bit, or debian unstable, or ..., > I would not expect they would fit perfect on all systems. > > > 4. How do these changes affect other distro packaging systems, such as > > RPM, etc. > > They do not affect other distros. > > > 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_o > > > > nly.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
