A few remarks on the python interface and hugin on non-***ix platforms: To run a python-enabled hugin, swig is not needed. Swig is only needed to create the python module which gives python access to hugin's functionality. The python module is simply a shared library which can be distributed as-is.
To run python-enabled hugin on a Linux machine, AFAIK (Linux machines always have python anyway) python isn't necessary. I've written the python interface so that it is only activated and initialized when the first call to it happens. So if python isn't there, hugin will run just fine, but trying to use python plugins will simply not work. On MacOS this should be the same. On Windows, the story is probably different: AFAIK, on Windows, all of hugin is linked statically. So I suppose the idea is that the shared library which constitutes the python module also has to be statically linked-in somehow. This is wrong. The python module is loaded by python when the need arises (like, a plugin is called). It may be though that trying to link everything statically also results in the python interpreter being statically linked to hugin (I'm not sure if or how this is done). I see no reason why this should be done, but on the other hand it's no big deal, since python is made to allow for such behaviour as well. I think the fixation on statically linking hugin with everything and using MSVC for the process is part of the problem. If you look at hugin as a ***ix-born program (is it?), MSVC is alien territory. Using MinGW would be much more appropriate, and then, along with using MinGW, all the libraries could be linked dynamically, just as on ***ix. The static linking comes, I think, from a specific notion: 'DLL hell', the problem that arisies from the fact that on Windows there seems to be confusion about where shared libraries should live, and from the fact that Windows doesn't have package management. I've heard that these issues have been adressed to some extent and the situation is much better now than it was a few years back, but the old fears still persist. So static linking and using MSVC becam the norm. The code is full of ugly conditional compiles and make directives which reflect the wrestling with WIndows'/MSVC's alien nature. From my (limited) experience with the code I would say that they often are expressed along the lines of '#ifdef Windows', rather than saying that they are for the specific 'statically linked+MSVC' combination. So if anyone tried to do the sane thing and use MinGW to create a dynamically- linked hugin using precisely the same tools which are used on ***ix, they would still be building for a Windows system, '#ifdef Windows' would be true, and the conditionals meant for statically-linked+MSVC hugin would fire, bending the code so that compiling a dynamically- linked+MinGW hugin is bound to fail. What to do? Someone with intimate knowledge of the code would have to go through the whole thing with a fine tooth comb to set things right. I doubt there is anyone willing to do that, after all the statically- linked+MSVC product works. I wonder: is there anyone (Thomas?) who has compiled an hsi module on Windows and would be willing to share it? Hsi is useful in itself, as it allows most of hugin's backend functionality to be used from python. The first step would be to try if and how this module works (or fails) on other Windows machines and what is really required to get it to run there. Then the next step would be to try out a python- enabled hugin to see if it can run on a system without python. I will not compile hugin on Windows myself, but I'll gladly test someone else's hsi module and python-enabled hugin on my Windows systems if this can help advance the cause of my brainchild. I can't help with MacOS, though. Kay -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
