On May 23, 2011 04:08:04 AM kfj wrote: > This probably does the trick: thank you. getting nearer. let's iterate once more.
> hsi/hpi for hugin is optional. It has to be compiled into hugin. This
> is done by defining BUILD_HSI=ON in the cmake command that sets up the
> code generation. Inside hugin's C++ code, there are some #defines that
> are relevant only for hsi/hpi:
this is already taken care of in the building instruction.
think of me as somebody who wants to expose more functionality to HSI.
The first thing is to include the header in /src/hugin_script_interface/hsi.i
right?
> HUGIN_HSI - this is defined globally if hsi/hpi capability has been
> switched on. It is used to introduce code which is hsi/hpi-specific
> into files which are also part of 'plain' hugin
so if I have to add extra code, I will put it inside an #ifdef HUGIN_HSI?
what are the situations you encountered when you had to add extra code?
find . -exec grep -l HUGIN_HSI {} \;
found it only in five files (three of them headers files)
in MainFrame.cpp/.h this is "just" the extra menu entry and in
wxPanoCommand.cpp/.h it is "just" to run the Python command.
the really relevant changes are in panodata/PanoramaVariable.h and from your
well commented code I understand (correct me if I am wrong) that the reason
for the slightly different class declaration is that SWIG requires an explicit
default constructor?
> SWIG - this is only defined when code is processed by SWIG. It's used
> to hide code from SWIG which it can't handle.
find . -exec grep -l SWIG {} \;
found it inside hugin_script_interface (obvious?) and inside seven header
files in /src/hugin_base/panodata, although most of them are false positive
(SWIG is in a comment). Again, your comment make it clear.
so if after adding a header to hsi.i some parts of it are not digested by
SWIG, or if there is no point in exposing them, I can use this to hide them?
> _HSI_IGNORE_SECTION - this is only defined during the separate C-
> preprocessing of certain hugin header files which use a technique
> dubbed 'lazy metaprogramming' which SWIG can't handle. Preprocessing
> 'flattens' the files - it pulls in all code that is #included by them.
> Most of the code pulled in this way mustn't be wrapped by SWIG, so it
> is switched off via #ifndef _HSI_IGNORE_SECTION.
by now my brain is frying. it does not help that it is close to midnight.
I see three instances of this and maybe I am generalizing, but isn't this
simply: all headers included in a headers are wrapped in HSI_IGNORE_SECTION
because SWIG can't handle them? and they are anyway fed into SWIG by being
listed in hsi.i ?
and now the jackpot question: what would be the next header file (or set of
header files) that given enough resources and time you would like to see
added to hsi.i?
I better go to sleep now.
Yuv
signature.asc
Description: This is a digitally signed message part.
