On 22 Jan., 11:16, "T. Modes" <[email protected]> wrote:
> > 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? > I commited a slightly modified version of your patch. > Some comments about the changes: > 1.) If you create swigpyrun.h in the source tree, it can happen (as in > your patch) that you pull in this file into the repository and > therefore the version management. An automatic created file should not > be in version management. So I removed this part. 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. > 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. Initially I was doing it with an #ifdef, but the difference can easily be seen by running diff on the two versions. Please consider, that every change to hugin header files triggers a major recompile, which takes a long time, and if the changes only affect hsi/hpi, this is a total waste of time. Once everything is stable, reverting to switching by #ifdef is a snap. As a temporary measure, it allows quick changes to the headers going into hsi and leaving the rest as it is. Also, I feel that ideally at least the changes to ImageVariable.h could beome unnecessary - I think it's safe to include default constructors for the classes, and I hope to get the PrintVariable class to work, so for this one there wouldn't be a need for different versions. If you insist, though, we can revert to the #ifdef _Hugin_SCRIPTING_INTERFACE solution I was using before. to reply to your previous post concerning your getting it to run on windows: > 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. concerning the accessors: > 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? you can't activate 'include all' for just one header file. To achieve this effect, it would be possible to make a separate i-file for the accessors, create another python module from that and load that when hsi is loaded. This separate i-file can be processed with different options like --include-all. The problem is that SrcPanoImage.h includes tons of other headers, which would all be pulled in and wrapped with --include-all if SRCPanoImage.h was %included whole by the i-file. This is certainly not what we want. What may be possible is to put the accessor macros into a separate header which can be %included by a separate i-file with --include-all to just generate the accessors. SrcPanoImage.h could also include this header, and everything should work both ways. I'll investigate and make a proposition if it's feasible. > > - 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 do feel it's a bit of a side issue, though - I've already spent a fair amount of time getting the accessor functions to run and I feel the time would be better spent in testing if they do what they're supposed to do. Anyway, I'll try and avoid the separate preprocessing step, but for now you can let hsi.i %include hsi_SrcPanoImage.h and have the accessors - all other code still uses the unmodifies SrcPanoImage.h and is unaffected by any experimentation. 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
