On Oct 4, 4:42 pm, Yuval Levy <goo...@levy.ch> wrote:
>
> AFAIK glut.dll should not be necessary. policy on Windows is to link
> statically to avoid problems with missing / disappearing dlls and other
> nice side effects of lack of proper package management.
>
> Possibly a bug in the build system that links nona-gpu dynamically.
OK, is that a line in a Cmake text file or is it more hidden in the
code? I'll report it as a bug.
>
> > Anyway, as far as I can remember the main problem in bringing out a
> > windows package (including dependencies) was enblend.
>
> actually it was three main issues with dependencies; and the enblend
> dependency got more complex:
>
> * libpano: there have been a couple of glitches. things seems to be
> solved / stable with the current SVN. The previous two beta releases
> where broken. Bruno intends to issue a new beta release soon, beta3 if I
> am not mistaken. => build against beta3 when it is out. Until it is out,
> build against most current SVN (trunk at revision 1096 works). Use the
> CMake build.
>
I had forgotten completely about the libpano issues. I was using a
version that I think I got from Guido's most recent SDK. I'll add
libpano in my SVN system and build the newer version. What exactly do
you mean when you say: use the CMake build?
> * autopano-sift-c: 2.5.0 suffer of major memory leaks and crashes often.
> 2.5.2 has other, major issues. 2.5.1 is a compromise interim release
> because we do not know when 2.5.2 will be fixed. 2.5.1 has not yet been
> released. => build from 2.5.1 beta tarball when it will be released.
> Until it is out, build from SVN 2.5.1 codeline.
2.5.1 on the sourceforge page is the RC1 version. I built that and it
worked without problems. Although I have to be honest and say I never
noticed the problems with 2.5.0 either. No crashes and if there were
memory leaks they were not severe enough to cause real problems. I
also built SVN version 4250, but it did not work, By that I mean that
it does build, I tried it with hugin, it seemed to run normally, but
no control points were found in a test sequence. I think an error
screen appeared for 0.1 second after the APSC run but I couldn't read
it.
>
> * enblend. ......
>
> The safe, conservative solution is to use the enblend/enfuse that are in
> the 0.7.0 binaries until the issues are sorted out. The better solution
> is to implement the choice of enblend (GPU, OpenMP, etc) in the
> installer, and deliver the 3.x binaries that were shipped with 0.7.0 as
> an additional choice. I still have to look into the upddated installer
> scripts that Ad published here a week or so ago.
I haven't looked at Ad's scripts yet, but I have my own customized
installer scripts that I could adapt. I remember I sent Ad my version
when he first started to make installers but I don't know what he has
changed since then. I think the 'choice' solution is good. I'll see if
I can figure out how to implement that, if not I'll be back with
questions. I would suggest also to add an option to install multiple
versions and let the user choose through the 'use alternative enblend
program' preference. Where do I get the different versions of
enblend?
Thanks, Allard
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
