Hi Kay, >But you got it to run? On Windows? That would be good news indeed, >because there are so many Windows hugin users out there, and I was >secretly afraid of subtle differences in SWIG and Python that might >make my code useless there.
Yes, it works. It has only a minor glitch. The output of the print command is not shown (a fear something similiar for an input function). But modifications to the pano object occur and appear also in hugin. On 21 Jan., 18:58, kfj <[email protected]> wrote: > On 21 Jan., 11:39, kfj <[email protected]> wrote: > > > ... I'll generate the required i-file code (so, code for SWIG) by means of > > a Python script.... > > ... hmmm ... that didn't work out either. So I've now settled on the > following aproach (which works but isn't very elegant): > What's with the following idea: Put all for SWIG unnecessary includes into #ifndef SWIG and then run swig with includeall? Can swig run with includeall on a single file or have we to modify all files in this case? > - I've preprocessed this section separately: gcc -E > hsi_SrcPanoImage_accessor_macros.h > xx That will not work on windows, because we are using an other compiler. > I've modified Thomas' CMakeList.txt code to generate swigpyrun.h in > the source tree instead of the target tree, but I still haven't > figured out how to have it made automatically initially - I can get > only get it to be created if I explicitly call make 'hsi_header'. That's a bad idea. We configured cmake so that all files are generated in the target tree to keep the source tree clean. So what's the reason for generating in the source tree? Thomas -- 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
