H Emad
Am 07.09.2010 06:22, schrieb Emad ud din Butt:
> Is there any precompiled build for Ubuntu available for latest hugin.
Not as far as I know. There was a launchpad project once upon time, but
the last time i looked, it lagged behind seriously.
> Is there any hugin builds
> like that with latest version. Or is there any way I can update
> my version 2009.2.0.4461 to latest hugin build.
Have a look at
http://wiki.panotools.org/Hugin_Compiling_Ubuntu
The whole process for compiling your own hugin is explained there. Just
follow these instructions step by step.
Have a nice day
Stefan Peter
- --
In theory there is no difference between theory and practice. In
practice there is.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMhd2wAAoJEBgqi52L7+L/13IH/jyLyhHrzGwCIC5Pm0aPYaOb
dKNDTKXnq0YHByc/b4gqUeYlik+CNuZivvIdkxpgl97Yv48kV3zj42HTRrEyybQ0
eQ4e9vDGYfuX85CuGh0Kff4ypw1VPJWBR1jLBXiAFRdJi3zNgWeKoSGC1osTRawa
eeNtkE4zqDVpOi5TKSOrPyYD+9RGuO+si7ep2D/gzxH19brkSXSO2mfFdN+KQ8MG
jak8n8suqg/ypieN9zhycEssZlqCdpkS3PCDeRWNvV4RAcqV318mneOyRS+hj/cY
nsOnCsE4jQyR+d+pMfeufcPd4VRZif9ide0VqMFY9THQU6nkCYaXzRUPohbdvM4=
=pOvC
-----END PGP SIGNATURE-----
Debian experimental has got 2010.2.0_beta2. Binary packages of the
latest release 2010.0.0 are available for lenny-backports, testing and
unstable on the Debian mirror network.
http://packages.debian.org/hugin
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Kornel
Try
# dpkg -L hugin | egrep bin/hugin
The name is "hugin", so I would expect "/usr/local/bin/hugin".
Please call this program from a terminal first. Then you may see, why it does not start.
Probably missing some shared library.
Try ldd /usr/local/bin/hugin to see, which libraries are not found.
> > *Emaad*
> > www.flickr.com/emaad
> >
> >
>
>
>
I'm interested in knowing what the command line says after you've
started hugin there as Kornel has suggested.
Dale
> --
> 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 hugi...@googlegroups.com
> To unsubscribe from this group, send email to hugin-ptx
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
Emaad,
I'm interested in knowing what the command line says after you've
started hugin there as Kornel has suggested.
Dale
On Wed, 2010-09-08 at 02:59 -0700, Emad ud din Btt wrote:
> I reboot system and now its shows Hugin in App > Graphics
>
> But when I click on it there is no response.
>
>
>
> On Wed, Sep 8, 2010 at 12:45 AM, Emad ud din Butt <xyz...@gmail.com>
> wrote:
> á á á á When I run this I get following message on Terminal...With Red
> á á á á fonts
>
> á á á á emaad@ubuntu:~$ dpkg -L hugin | egrep bin/hugin
> á á á á /usr/local/bin/hugin_stitch_project
> á á á á /usr/local/bin/hugin_hdrmerge
> á á á á /usr/local/bin/hugin
>
> á á á á I have checked /usr/local/bin directory. All files are there.
> á á á á But I dont understand whats the reason of red font.
>
>
>
>
>
>
>
>
> á á á á On Wed, Sep 8, 2010 at 12:32 AM, Kornel Benko
> á á á á <Kornel...@berlin.de> wrote:
> á á á á á á á á Am Mittwoch, 8. September 2010 schrieb Emad ud din
> á á á á á á á á Butt:
>
> á á á á á á á á > It displays whole llist of files. But where is hugin
> á á á á á á á á GUI? I have to manually
> á á á á á á á á > add a shortcut or it will be auto added into Apps
> á á á á á á á á list?
>
>
> á á á á á á á á Try
> á á á á á á á á á á á á# dpkg -L hugin | egrep bin/hugin
>
> á á á á á á á á The name is "hugin", so I would expect
> á á á á á á á á "/usr/local/bin/hugin".
>
>
> á á á á á á á á >
> á á á á á á á á > On Wed, Sep 8, 2010 at 12:09 PM, Kornel Benko
> á á á á á á á á <Kornel...@berlin.de>wrote:
> á á á á á á á á >
> á á á á á á á á > > Am Mittwoch, 8. September 2010 schrieb Emad ud din
> á á á á á á á á Butt:
> á á á á á á á á > > > Hi Dale,
> á á á á á á á á > > >
> á á á á á á á á > > > Many thanks....I have downloaded .deb files.
> á á á á á á á á Double clicked and it opened
> á á á á á á á á > > in
> á á á á á á á á > > > package manager.
> á á á á á á á á > > >
> á á á á á á á á > > > I first installed dependencies using Terminal
> á á á á á á á á > > > Than I install Base Install i.e. enblend,
> á á á á á á á á libpano and than hugin.
> á á á á á á á á > > > Than I insalled image exif, panoglow etc.
> á á á á á á á á > > > Than sudo Idconfig
> á á á á á á á á > > >
> á á á á á á á á > > > All installed perfectly and it is shown in
> á á á á á á á á package manager. But where can
> á á á á á á á á > > i
> á á á á á á á á > > > find hugin. Its not being shown in applications.
> á á á á á á á á I have tried to open it
> á á á á á á á á > > > from /usr/local/bin/hugin but no response. How
> á á á á á á á á can I fix it? I am using
> á á á á á á á á > > > ubuntu-10.04.1-desktop-i386
> á á á á á á á á > > >
> á á á á á á á á > > >
> á á á á á á á á > > If everything is installed, you may check with
> á á á á á á á á > > á á á á# dpkg -L hugin
> á á á á á á á á > > to get the list of all installed files.
> á á á á á á á á > >
> á á á á á á á á > > á á á áKornel
> á á á á á á á á > >
> á á á á á á á á >
> á á á á á á á á >
> á á á á á á á á >
> á á á á á á á á >
>
>
>
>
>
>
> á á á á --
>
>
>
> á á á á Emaad
> á á á á www.flickr.com/emaad
>
>
>
>
>
> --
>
>
> Emaad
> www.flickr.com/emaad
>
>
>
Emaad,
I'm interested in knowing what the command line says after you've
started hugin there as Kornel has suggested.
Dale
On Wed, 2010-09-08 at 02:59 -0700, Emad ud din Btt wrote:
> I reboot system and now its shows Hugin in App > Graphics
>
> But when I click on it there is no response.
>
>
>
> On Wed, Sep 8, 2010 at 12:45 AM, Emad ud din Butt <xyz...@gmail.com>
> wrote:
Emaad,
I'm interested in knowing what the command line says after you've
started hugin there as Kornel has suggested.
Dale
On Wed, 2010-09-08 at 02:59 -0700, Emad ud din Btt wrote:
> I reboot system and now its shows Hugin in App > Graphics
>
> But when I click on it there is no response.
>
>
>
> On Wed, Sep 8, 2010 at 12:45 AM, Emad ud din Butt <xyz...@gmail.com>
> wrote:
Emaad,
We should add this dependencies for debian in CMakeLists.txt. (RPM does this automatically!) But I fear, the list may be too long, and it depends on how
hugin is built. On my system (ubuntu 10.04, 64bit) it would be (line 513):
...
set(CPACK_DEBIAN_PACKAGE_DEPENDS "freeglut3 (>= 2.6.0-0),libatlas3gf-base (>= 3.6.0-24),libboost-date-time1.38.0 (>= 1.38.0-6),libboost-thread1.38.0 (>= 1.38.0-6),libexiv2-6 (>=0.19-1),libglew1.5
(>= 1.5.2-0),libopenexr6 (>= 1.6.1-4.1),libpano13 (>= 2.9.17),libwxgtk2.8-0 (>= 2.8.10.1-0)")
...
Maybe some statements like e.g.
if(wxWidgets_FOUND)
sett(CPACK_DEBIAN_PACKAGE_DEPENDS "libwxgtk2.8-0 (>= 2.8.10.1-0),${CPACK_DEBIAN_PACKAGE_DEPENDS}")
endif()
etc.
Kornel
> > Dale
> >
--
Kornel Benko
Kornel...@berlin.de
>> On Wed, Sep 8, 2010 at 9:13 PM, Dale Beams <drb...@hotmail.com> wrote:
>> > You'll also need:
>> > sudo aptitude install libwxbase2.8-0
> We should add this dependencies for debian in CMakeLists.txt. (RPM
> does this automatically!)
[...]
Just for clarification: "Proper" Debian source packages also do this
automatically. This is just cmake's broken idea of builing a debian
format package.
cu andreas
I created a perl script to extract the list of needed packages for a given list of executables.
But it takes some looong time to do its job, therefore not applicable to automatically execute.
The algorithm is following:
1.) determine all used shared libraries (parse output of "ldd {executable}")
2.) determine to which package they belong (parse output of "dpkg -S {library}")
3.) determine prerequisites of each package (parse output of "dpkg -s {package}")
4.) remove each package which is already a prerequisite of another package
5.) print the list of remaining packages
> I noticed the CPACK_DEBIAN_PACKAGE_DEPENDS="libpano13" in the hugin
> CMakeLists.txt a couple of weeks ago and was going to suggest doing this
> for enblend as well but have been so busy with work I've not been able to
> get around to it.
Yes, enblend/enfuse needs this too :(
> I think the build instructions on the web is wonderful and don't think I
> could have put them togather myself. I'd like to clean them up, as well
> as possible create seperate pages for seperate releases (ie, 9.04, 9.10).
> Or at least for the supported releases from Ubuntu. One of the things I
> noticed is that not all dependenices are listed the further you move down
> the list, but assumed because they've been already installed previously
> for other builds. However this presents a problem for builds such as
> PanoGLViewer, etc.
>
> I've also began stepping through each build to determine if every
> dependenciy is needed during the build, during the installation, and what
> it belongs to. For example, Enblend only needs four dependencies to
> install after the build.
Interesting. My script gives me
freeglut3 (>= 2.6.0-0),\
libboost-filesystem1.38.0 (>= 1.38.0-6),\
libglew1.5 (>= 1.5.2-0),libgomp1 (>= 4.4.3-4),\
liblcms1 (>= 1.18.dfsg-1),\
libopenexr6 (>= 1.6.1-4.1),\
libplot2c2 (>= 2.6-0),\
libtiff4 (>= 3.9.2-2)
==> 7 dependencies for enblend/enfuse
> The build instructions also list packages that I don't believe are being
> maintaned or used anymore. Matchpoint, FreePV, etc. Perhaps those should
> be moved to a section "Archived, No longer maintained. Autotools is
> another section that should be archived imho.
>
> I've attached a "fasttrack" build script. It's incomplete, but should be
> uniform. I'd planned on introducing dependencies previous modification of
> the CMakeLists.txt by "echo CMAKE_DEBIAN ... etc >> CMakeLists.txt"
> (syntax is not correct but you get the idea).
The list has to be known before calling CPack ...
> I'd eventually liked to get a very streamlined set of build instructions
> for each Ubuntu release, a fast track build script so that there is less
> confusion. There are several comments that have been returned to me that
> I'm trying to address
>
> 1. Hugin is anything but simple to use.
> 2. There's no way I'm going to try to build that, it looks to complicated.
> Do you have binaries? 3. Where can I find how to do this or that?
>
> I looked on wikipedia on the math behind a simple equalateral (spelling?)
> projection and finally got a real understanding of the complexity of the
> math behind Hugin and releated programs. I realize it's no easy task, nor
> is it an easy task building tutorials, workflow, etc. Add to that most
> people work for a living and what does get's posted is done with precious
> spare time. I'm really looking for a way to simplify understanding,
> installation, building for an average desktop user.
>
> Dale
>
> Fast Track Script - http://www.tatteredmoons.org/hugin/fasttrack.sh
This one comes in firefox as:
Error 404: NOT FOUND!
Your browser cannot find the document corresponding to the URL you typed in.
--
Kornel Benko
Kornel...@berlin.de
This is my problem, published the e-mail before fixing the web link.
This will work now.
http://www.tatteredmoons.org/hugin/fasttrack.sh
It's incomplete and untested
Dale
Interesting. I have something appropriate, but as a perl script.
Same need :)
Kornel
--
Kornel Benko
Kornel...@berlin.de
I'm guessing you have a better idea what needs to be done.
I'm swamped at work and am doing this very slowly on the side.
Dale
/* Enblend */
cd ~/src/enblend
hg clone http://enblend.hg.sourceforge.net:8000/hgroot/enblend/enblend
enblend.hg
cd ~/src/enblend/enblend.build
echo "CPACK_DEBIAN_PACKAGE_DEPENDS="libpost2c2 libglew1.5 freeglut3
libboost-filesystem1.40.0 liblcms1 libopenexr6 libtiff4"" >>
CMakeList.txt
cmake ../enblend.hg -DENABLE_GPU:BOOL=ON -DENABLE_IMAGECACHE:BOOL=OFF
-DENABLE_OPENMP:BOOL=ON \
-DCPACK_BINARY_DEB:BOOL=ON -DCPACK_BINARY_NSIS:BOOL=OFF
-DCPACK_BINARY_RPM:BOOL=OFF \
-DCPACK_BINARY_STGZ:BOOL=OFF -DCPACK_BINARY_TBZ2:BOOL=OFF
-DCPACK_BINARY_TGZ:BOOL=OFF \
-DCPACK_BINARY_TZ:BOOL=OFF
make package
sudo dpkg -i enblend*.deb
cp *.deb ~/deb/hugin
On Thu, 2010-09-09 at 20:47 +0200, Kornel Benko wrote:
>
This cannot work. CMakeList.txt is a cmake file. It's syntax is not that of a shell.
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)
....
> cmake ../enblend.hg -DENABLE_GPU:BOOL=ON -DENABLE_IMAGECACHE:BOOL=OFF
> -DENABLE_OPENMP:BOOL=ON \
> -DCPACK_BINARY_DEB:BOOL=ON -DCPACK_BINARY_NSIS:BOOL=OFF
> -DCPACK_BINARY_RPM:BOOL=OFF \
> -DCPACK_BINARY_STGZ:BOOL=OFF -DCPACK_BINARY_TBZ2:BOOL=OFF
> -DCPACK_BINARY_TGZ:BOOL=OFF \
> -DCPACK_BINARY_TZ:BOOL=OFF
> make package
> sudo dpkg -i enblend*.deb
You may have here more than one package ...
> cp *.deb ~/deb/hugin
>
> On Thu, 2010-09-09 at 20:47 +0200, Kornel Benko wrote:
> > Interesting. My script gives me
> >
> > freeglut3 (>= 2.6.0-0),\
> > libboost-filesystem1.38.0 (>= 1.38.0-6),\
> > libglew1.5 (>= 1.5.2-0),libgomp1 (>= 4.4.3-4),\
> > liblcms1 (>= 1.18.dfsg-1),\
> > libopenexr6 (>= 1.6.1-4.1),\
> > libplot2c2 (>= 2.6-0),\
> > libtiff4 (>= 3.9.2-2)
> >
> > ==> 7 dependencies for enblend/enfuse
Kornel
--
Kornel Benko
Kornel...@berlin.de
dpkg-shlibdeps(1) already exists.
> But it takes some looong time to do its job, therefore not
> applicable to automatically execute.
> The algorithm is following:
> 1.) determine all used shared libraries (parse output of "ldd
> {executable}")
ldd lists both dependencies and dependencies of dependencies, objdump
-p ... | grep NEEDED would be the correct tool.
> 2.) determine to which package they belong (parse output of
> "dpkg -S {library}")
> 3.) determine prerequisites of each package (parse output of
> "dpkg -s {package}")
[...]
Why?
cu andreas
It does not work here. Insists on opening file "debian/control".
There _are_ some such files on my system, but only for some self compiled programs.
> > But it takes some looong time to do its job, therefore not
> > applicable to automatically execute.
> >
> > The algorithm is following:
> > 1.) determine all used shared libraries (parse output of "ldd
> > {executable}")
>
> ldd lists both dependencies and dependencies of dependencies, objdump
> -p ... | grep NEEDED would be the correct tool.
"ldd -v" lists both dependencies and ...
ldd alone not.
> > 2.) determine to which package they belong (parse output of
> > "dpkg -S {library}")
> > 3.) determine prerequisites of each package (parse output of
> > "dpkg -s {package}")
>
> [...]
>
> Why?
Because I try to ignore subsequent dependencies .
if "a" depends on "b,c,d,e,f"
and "b" depends on "c,e,f"
then it is enough to say "a" depends on "b,d"
> cu andreas
>> ldd lists both dependencies and dependencies of dependencies, objdump
>> -p ... | grep NEEDED would be the correct tool.
> "ldd -v" lists both dependencies and ...
> ldd alone not.
EPARSE.
For clarification:
ametzler@argenau:~$ objdump -p /usr/bin/curl | grep NEEDED
NEEDED libcurl.so.4
NEEDED libz.so.1
NEEDED libc.so.6
NEEDED librt.so.1
ametzler@argenau:~$ ldd /usr/bin/curl
linux-gate.so.1 => (0xf775b000)
libcurl.so.4 => /usr/lib/libcurl.so.4 (0xf7707000)
libz.so.1 => /usr/lib/libz.so.1 (0xf76f2000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xf7596000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xf758d000)
libidn.so.11 => /usr/lib/libidn.so.11 (0xf755c000)
libssh2.so.1 => /usr/lib/libssh2.so.1 (0xf753b000)
liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0xf752d000)
libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0xf74ea000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xf74bf000)
libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xf7479000)
libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xf7326000)
/lib/ld-linux.so.2 (0xf775c000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xf730d000)
libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xf72a5000)
libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xf72a1000)
libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xf7287000)
libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xf7273000)
libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xf725c000)
libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0xf71bf000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf712b000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf7106000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xf7103000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xf70fb000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xf70f7000)
libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xf70f4000)
libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xf70e3000)
The curl binary depends on libcurl, zlib libc and librt. ldd does not
only list /usr/bin/curl dependencies, but also the dependencies of
libcurl, zlib libc and librt. The dependencies of the curl package
itself should only list the direct dependencies.
cu andreas
do you mean that our CMake build is incomplete? or that CMake can't build
proper debian packages?
Yuv
done! I neded a changeset to test tweaking to the email notifications from
the repo.
thanks
Yuv
Nice, but Andreas, but we want dependences from package, not from library.
Nonetheless, I overlooked the "objdump" call in your previous mail.
This command used on enblend gives a list of 29 libraries, not much different to ldd (which gives 41),
so it's not that much better.
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.
> thanks
> Yuv
fixed. there is a syntax for version numbers. Refernce [0]
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?
* 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?
* we do not set the maintainer, which is Debian-mandatory.
CPACK_DEBIAN_PACKAGE_MAINTAINER
* 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?
* what can/should we do with the recommended fields (section / priority /
recommends / suggests / control extra) ?
* Anything else I am missing on the way to a proper Debian package out of
CMake?
Yuv
[0]
http://www.paraview.org/Wiki/CMake:CPackPackageGenerators#DEB_.28UNIX_only.29
[...]
Hello,
afaik from the results (see e.g.
http://mid.gmane.org/kdsci7-...@argenau.downhill.at.eu.org or
discussions on debian-devel) the latter. The results seem to be
similar to what one would if he tried building rpms using cpio instead
of rpm. The breakage that actually seems to cause pain is that package
dependencies are incorrect or missing. (Even using alien to convert
the rpm would give better results in this respect).
One of or probably the strongest point of Debian is that we have a
policy that describes in great detail how packages must look like to
make it possible that the packages work together and upgrade
correctly. cmake built packages seem to ignore many parts of it.
cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
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 ...
kornel
Hello,
http://www.debian.org/doc/debian-policy/
http://www.debian.org/doc/developers-reference/
cu andreas
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
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.
--
Kornel Benko
Kornel...@berlin.de
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
It was me.
1.) Location
2.) Syntax
> 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
Defaults are set in CPack.cmake in _your_ system if not specified by us.
We have to know package management prior to setting our default.
> 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?
True, this looks like it were not optional.
For enblend we should make them required.
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "libpano13(>=2.9.17), libpost2c2,
libglew(>=1.5), freeglut3, libboost-filesystem(>=1.38.0), liblcms1,
libopenexr6, libtiff4")
Which appears to set debian package dependencies at >= for certian
packages. I assume this can be set for all packages negating the need
to hard set any package dependencies and guaranteeing that the build
would work so long as the system had >= package. Correct?
On Mon, 2010-09-13 at 19:18 +0200, Kornel Benko wrote:
> Am Montag 13 September 2010 schrieb Dale Beams:
> > 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?
>
> It was me.
> 1.) Location
> 2.) Syntax
>
> > I'd have to dig around for the e-mail, but someone indicated that
> >
Since most of Hugin programmers are using scripts to build for testing,
I'd assume that "-DCPACK_BINARY_PACKAGE-TYPE:BOOL=off" could be set for
the default for all packages and then the FAQ could be simplified by
removing:
cmake ../apsc.hg -DCMAKE_INSTALL_PREFIX=/usr/local
-DCPACK_BINARY_DEB:BOOL=ON \
-DCPACK_BINARY_NSIS:BOOL=OFF -DCPACK_BINARY_RPM:BOOL=OFF
-DCPACK_BINARY_STGZ:BOOL=OFF \
-DCPACK_BINARY_TBZ2:BOOL=OFF -DCPACK_BINARY_TGZ:BOOL=OFF
-DCPACK_BINARY_TZ:BOOL=OFF
and replacing it with
"cmake ../program.hg -DCMAKE_INSTALL_PREFIX=/usr/local
-DCPACK_BINARY_PACKAGE-TYPE:BOOL=on"
for each individual build, simplifying that build instruction to one
line in the FAQ?
I assume the reason it builds all package-types now is a programming
default?
Dale
Not exactly. This _are_ the hardcoded (for now) package dependencies. Not sure about debian.
(All of them but libpost2c2 are on my system, but not exactly)
Therefore I had now problem to use this package. This is what I had to do locally, inserting _my_ dependencies:
SET(CPACK_DEBIAN_PACKAGE_DEPENDS "freeglut3 (>= 2.6.0-0),libatlas3gf-base (>= 3.6.0-24),libboost-date-time1.38.0 (>= 1.38.0-6),libboost-thread1.38.0 (>= 1.38.0-6),libexiv2-6 (>=
0.19-1),libglew1.5 (>= 1.5.2-0),libopenexr6 (>= 1.6.1-4.1),libpano13 (>= 2.9.17),libwxgtk2.8-0 (>= 2.8.10.1-0)")
As I somewhere said, this looks totally system-dependent. I don't know, how to overcome this.
Yuv, maybe we should go back again, until there is some automated method in cmake itself. This hard-coding
looks not promising for me.
Dale
that's what I would expect too. Let's try it, and if it does not work we can
roll back to no dependency specified at all. It does work for RPMs, though...
Yuv
user@Ubuntu:~/src/hugin/hugin.build$ sudo dpkg -i
hugin-2010.3.0-Linux.deb
(Reading database ... 195430 files and directories currently installed.)
Preparing to replace hugin 2010.3.0 (using hugin-2010.3.0-Linux.deb) ...
Unpacking replacement hugin ...
dpkg: dependency problems prevent configuration of hugin:
hugin depends on libpost2c2; however:
Package libpost2c2 is not installed.
hugin depends on libglew (>= 1.5); however:
Package libglew is not installed.
hugin depends on libboost-filesystem (>= 1.38.0); however:
Package libboost-filesystem is not installed.
dpkg: error processing hugin (--install):
dependency problems - leaving unconfigured
Processing triggers for man-db ...
Errors were encountered while processing:
hugin
user@Ubuntu:~/src/hugin/hugin.build$ sudo aptitude search libpost2c2
libglew libboost-filesystem
i libboost-filesystem-dev
- filesystem operations in C++ (default
version)
i A libboost-filesystem1.40-dev
- filesystem operations (portable paths, iteration over directories,
etc) in C++
i A libboost-filesystem1.40.0
- filesystem operations (portable paths, iteration over directories,
etc) in C++
v libglew-dev
-
i A libglew1.5
- The OpenGL Extension Wrangler - runtime
environment
i libglew1.5-dev
- The OpenGL Extension Wrangler - development
environment
v libglewmx-dev
-
p libglewmx1.5
- The OpenGL Extension Wrangler - runtime
environment
p libglewmx1.5-dev
- The OpenGL Extension Wrangler - development environment
the .deb file works off-line *if* you have all the dependencies already
installed.
there is not much that can be "made" other than maybe putting all of those
.deb files in a single place.
to achieve your goal, you need to copy all the dependencies' .deb files with
the Hugin .deb file to your off-line install media (CD/DVD/USB stick).
Yuv