On Sat, May 15, 2010 at 5:28 AM, Tom Glastonbury <tg-VlzpuMDywAyhBdjdy8MwptBPR1lH4CV8@public.gmane.org>
Thanks for your message.
First off, let me note that this is my first open source project, so
I'm not really clued up about the etiquette, procedures and so on of
how it all works from a development perspective. For example, I've just
had an email from Thomas Modes (via hugin-ptx) noting that I can submit
patches including diff files via the patch tracker. However, I assume
that if I am to work on getting the whole Windows SDK into SCC, I'd
need permission to check in directly. How does that happen? Also, I
note that my suggested change to ver 0.19 of exiv2 was implicitly
accepted by Thomas Modes as he checked in the required changes:
however, I might have expected there to be some review process,
allowing others to have the opportunity to chime in and say "oh no,
there's such-and-such a problem with that version, we can't use it". Or
does it mean that I'm free to update to a new version of a 3rd party
library without consultation?
It seems to me that Hugin is less structured than many open source communities -- it has no formal submission or review process, and relies mostly on the expertise and good character of its contributors. To check into the source archive you just need to be designated as a Hugin developer on Source Forge. As a developer you can also add new subdirectories and even create new branches (it is just a virtual copy operation, no impact on old files).
My own opinion is that one should modify 3rd party libraries only as a very last resort, because creating local variants of published packages creates all kinds of maintenance problems. Usually there is some way to get the same effect with glue code; and many packages let you customize them with configuration files, which are supposed to be local.
You mention Bruno - who is he? What's his email address? And you
mention matters of configuration - do you mean SCC configuration, CMake
configuration or some other configuration?
Bruno Postle (bruno-I6Uu+xO5j5OsTnJN9+BGXg@public.gmane.org
) is a Hugin (and PanoTools) admin who has been involved from the beginning and probably knows what is going on better than Pablo or Yuval Levy. He is not a C++ programmer but is very good with scripting and applications (for example: ).
I generally rely on Bruno's opinions as to what makes sense for the project.
One way to get the attention of the Hugin admins and several active developers is to use PanoTools developer mailing list at SF, to which I'm forwarding this message (oddly there is no hugin-devel list). Another is via the Google group on Hugin: http://groups.google.com/group/hugin-ptx
I'm happy to produce the Windows snapshots as this would seem to be
very helpful for a lot of people out there. Would the
binaries/installer get hosted at the Sourceforge project?
I would favor that, however Hugin traditionally does not put snapshot builds on SF. Ask Bruno.
That is the right source. Windows builds should preferably use the CMake scripts to build libpano13, as the VC projects are unstable -- they contain lots of local state, which changes depending on who last committed them.
2. The biggest problem I see at present, notably when producing 32 and
64 bit builds, is that there seems to be no support for the coexistence
of 32 and 64 bit libs and dlls being built in the SDK - in fact the
Wiki instructions require that in several cases I copy the x64 .lib
files to where the 32 bit ones would normally live. Even if the SDK
were "fixed", it appears to me that the CMake files within hugin that
go looking for external libs have no mechanism for finding 32 and 64
bit libs, and producing make/VC files that link to different libs
depending upon the target architecture. From my very limited knowledge
of CMake, this would require quite a lot of work.
As far as I can see, the only way around this at present is to maintain
two copies of the SDK, one producing 32-bit libs and the other
producing 64-bit ones.
3. If I'm sorting the Windows SDK out, I'd suggest using VC2010 Express
rather than the now out-dated VS2008. Do you see any problem with this?
No knowledge. But I certainly would not like to see the code to get incompatible with 2008 as lots of people have that.
On 14/05/2010 9:29 PM, Thomas Sharpless wrote:
I think it would be great if you take up building Windows snapshots
regularly. 32 and 64 bit.
The two biggest outstanding problems with the Windows SDK , to my
limited knowledge, are 1) it is not under SCC at the Hugin archive, and
should be; 2) it includes a source tree for libpano13, and should not.
The official PanoTools source now has the CMake scripts for building
libpano13 in the SDK environment (they sort of work on Linux, too, but
Linux builders rarely use them) so it should not be hard to revise the
SDK to use the current Panotools source and get rid of the bootleg one.
As always, I recommend you get Bruno's wisdom about all matters of
Good luck with this,
On Thu, May 13, 2010 at 4:02 PM, Tom
I looked at Zoran's page, but he doesn't do 64-bit builds. I have
myself since produced a working win x64 svn 5145 build, and have posted
a message to the hugin-ptx group. As per that message, I needed to make
some modifications to the source code, the cmake files and the versions
of some 3rd party libraries. Zoran has since written to me asking me to
"dump the sdk" to his ftp server, but this is not so trivial as without
selectively deleting intermediate files (and perhaps binaries) it's
over 9GB large. Regardless, I did write to Pablo before posting to the
group, and he suggested:
Currently, we do not have somebody who
takes care of the windows releases (neither 32 nor 64 bit), but I think
a 64 bit windows build is on the wishlist for quite some people. I
haven't build hugin on windows since a two years or so, thus my
experience with the current windows sdk is limited. I think the
straightforward way to contribute (after talking a litte on hugin-ptx)
would be to post the windows 64 bit SDK for everybodys usage and adding
usage instructions to the relevant wiki pages.
So I'd rather be able to have my changes checked in (subject to review
etc), and then do as Pablo suggested. As such, I'd be grateful if I
could get some feedback from the active admins/developers on the
On 05/05/2010 2:59 PM, Thomas Sharpless wrote:
I'm not set up to do 64 bit Windows builds, and have kind of retired
from doing regular snapshot builds. I think you can get an up to date
64 bit one at http://lemur.dreamhosters.com/hugin/,
thanks to Zoran Zorkic.
Keep in touch with Hugin development at http://groups.google.com/group/hugin-ptx
On Wed, May 5, 2010 at 5:47 AM, Tom
I've just stumbled across your builds of autopano-sift-c and the latest
hugin - thanks very much for producing these. I was wondering if you've
considered producing 64-bit builds, and if the source code is designed
to take advantage of the features of 64-bit processors? Do you think
there'd be much improvement, performance-wise?