Hi Kay, > swigpyrun.h is input. It is included by hpi_classes.h which is in turn > included by hpi.cpp. This is why it is needed in the source tree. It's > needed in the making of the hpi object code which is then linked into > libhugin.so, but is irrelevant further down the road and does not > belong to the output. But it should be generated anew every time the i- > file is processed, to reflect possible changes in the SWIG-generated > data structure.
It's not needed in the source tree. The compiling and linking work also if the file is in the build tree (when the paths are configured right). So it works e.g. with hugin_config.h, where some platform/user specific things are defined. So no need to generated in the source tree with all implications. > > > 2.) There is no need for 2 versions of PanoramaVariable.h. The little > > difference for hugin and swig can easily achieved by an ifndef. So > > there is only one version and you don't handle with synchronisation of > > 2 versions of the same file. > > I felt this was the cleaner solution while hsi is still under > development. </snip> Ok, I did not see this point. > > 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. > > did you start hugin from the command line? If not, there's no way you > can see anything, the prints just go into thin air. The affectiveness > of the modifications to the panorama are the main thing; the print > statements in hpi.py and demo_plugin.py are only as a quick proof that > something goes wrong or right. But hugin must be started in a console > window to see them. Yes, also tested on console, but this does not help because the console works in an other way than on unix. > > > - 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'm confident that every C++ compiler in existence offers separate > precompilation. But as stated in the previous section I will try and > find a solution to avoid this. I finally found a solution to automatically create the preprocessed file and input it into the swig process. So there is no need to fiddle by hand with the preprocessing and there are not 2 version of the same file which needs to be in sync (commited in 25f830e2d143). So you can further testing now. 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
