Hi Tom

On Sat, May 15, 2010 at 5:28 AM, Tom Glastonbury <tg@tomglastonbury.com> wrote:
Hi Tom,

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@postle.net) 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.

Regarding the current Windows SDK:

1. The libpano13 I used (having followed the instructions at http://wiki.panotools.org/Hugin_SDK_%28MSVC_2008%29#Panorama_Tools) comes from:

https://panotools.svn.sourceforge.net/svnroot/panotools/trunk/libpano

Is that the right source? The SDK docs don't use CMake for libpano, instead relying upon a pre-existing .sln file (although it's for an older version of VC but apparently auto-converts to vs2008 without problems.

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.

Regards, Tom

Many thanks,

Tom


On 14/05/2010 9:29 PM, Thomas Sharpless wrote:
Hi Tom

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 configuration.

Good luck with this,
Tom


On Thu, May 13, 2010 at 4:02 PM, Tom Glastonbury <tg@tomglastonbury.com> wrote:
Hi 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 really 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 project.

Many thanks,

Tom


On 05/05/2010 2:59 PM, Thomas Sharpless wrote:
Hi Tom

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

Regards, Tom


On Wed, May 5, 2010 at 5:47 AM, Tom Glastonbury <tg@tomglastonbury.com> wrote:
Hi there 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?

Many thanks,

Tom Glastonbury