On 24 Mai, 05:45, Yuval Levy <[email protected]> wrote:
> 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.
okay. leaves the headline 'preprocessor defines that are relevant for
hsi/hpi'
> 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?
correct. hsi.i is the central location. And CMakeLists.txt in the
hugin_script_interface directory has to be told that hsi.i has an
additional dependency by putting it into the wrappee list:
SET(hsi_wrappees
...
"${HUGIN_BASE_DIR}/somedirectory/someheader.h"
...
If the header in question uses 'lazy metaprogramming' more trickery is
needed (see comments below)
> > 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?
If you want to add code anywhere inside hugin which will only work if
an hsi/hpi-enabled version is built, you put it into an #ifdef
HUGIN_HSI. If the code is in one of the files which are only touched
when an hsi-enabled version is built (files in the
hugin_script_interface directory) it's of course unnecessary. That'
why
> find . -exec grep -l HUGIN_HSI {} \;
>
> found it only in five files (three of them headers files)
because the only code outside the hugin_script_interface directory
that calls hsi/hpi code is the bit implementing the 'call Python
script' menu entry, so it has to pull in hpi with a header and contain
code to show and handle the menu entry.
> in MainFrame.cpp/.h this is "just" the extra menu entry and in
> wxPanoCommand.cpp/.h it is "just" to run the Python command.
Precisely. That's it. Currently, hugin makes no more use of the hsi/
hpi interface than this.
> 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?
Yes. Not soooo relevent I suppose - I assume that there isn't really a
reason not to have a default constructor there, but when I nudged my
code in I tried to be as unobtrusive as possible - and I made no
attempt to understand the byzantine intricacies of hugin's object
jungle ;-)
> > 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.
There are some things which SWIG just can't handle. SWIG isn't defined
when the code is used as C++, but only when swig processes it. So the
#ifndef SWIG just prevents SWIG from seeing it but for the remainder
of the project the code is there as ever.
> 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?
yes. It'll hide them from SWIG, but all other code will see them
(unless you do silly things like define SWIG yourself ;-)
SWIG actually understands C/C++. It's pretty much a compiler in it's
own right, just that it doesn't produce object code but C code that
can be translated into modules for other languages. So if you put
something after #ifndef SWIG, only swig's processing is affected,
nothing else.
> > _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 ?
I toasted my brain for weeks to find a solution to deal with 'lazy
metaprogramming'. Let me explain. The technique is used in several
hugin header files that define member access for objects with large
numbers of members, like image variables. Of these variables there are
a great many, and all of them want a gettor, settor, deletor and so
forth. So whoever designed this code decided to implemet the accessors
using macros. A macro is defined in the header file, and right after
that definition another header file is included that invokes the macro
for every member variable in turn with additional parameters as befit
that member (name, type, size, etc.), so that the invocations of the
macro create the accessors. For the next type of accessor, the same
macro is redifined (like, 'set' instead of 'get') and the same header
with the macro invocations is included again, now obviously producing
a new set of accessor functions.
This sort of evil trickery works in C++ (even though it's really
intransparent and IMHO bad style), but SWIG can't cope with it - I
tried everything I could think of, but it plain wouldn't work - the
problem is the redefinition of the macro and the multiple inclusion of
the header; swig ecpects headers to be included once with the effect
of their contents being known henceforth. The only way to deal with it
was to C- preprocess the code in question. But C-preprocessing expands
every #include and #define, and swig wraps every declaration it sees
at the top level. So if the whole header is preprocessed, everything
that it includes would also be wrapped - not what you want. So the
parts of the headers that include other headers are exempt from the C-
preprocessing with _HSI_IGNORE_SECTION only for the C-preprocessing
they are submitted to before they are fed into swig. In all other
situations they are compiled normally.
Sorry for the complicated mechanism - but it works.
> 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?
There's already a large number of headers included, and while I was
working with hsi/hpi I added what I felt was missing. I also started a
thread on the topic, and I included what was proposed.
http://groups.google.com/group/hugin-ptx/browse_thread/thread/e0d36a1792a2f4ce/478766ed0f7b848e?lnk=gst&q=what+should+go+into+the+python#478766ed0f7b848e
Currently I can't think of anything more - I'd propose to just leave
it as it is until someone comes up with wishes. If the header in
question is simple, often enough it's a one-liner in hsi.i, and the
cmake file has to be modified so the new wrappee is recognized as a
dependency for hsi.i.
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
