I'm porting code from wxWidgets to Qt, and the old SWIG python binding scheme
seemed inappropriate for for Qt, so I switched to PySide and Shiboken.  Our
code uses boost signals and slots, and trying to minimize effort I have not
(yet) translated all the boost signals into Qt signals.

Shiboken works for me to generate bindings to a few of my classes, but when I
got to the first class that uses boost signals, it started crashing during
binding generation.

Here is my global.h, trimmed to just the failing part.

#undef QT_NO_STL
#undef QT_NO_STL_WCHAR

#ifndef NULL
#define NULL 0
#endif

#include "pyside_global.h"

#include <QtCore/QtCore>
#include <QtGui/QtGui>

#include <boost/signal.hpp>

Without the #include <boost/signal.hpp> it works fine.

The problem seems to lie in an infinite recursion of rpp::pp::handle_include()
in apiextractor-0.10.9/parser/rpp/pp-engine-bits.h.  I looked at the crash in
gdb and the stack was very very tall, filled only with calls to that function.

Here is the top of that tall stack:

#40891 0x00007ffff78d75d6 in __gnu_cxx::__normal_iterator<char*, std::string>
rpp::pp::handle_include<__gnu_cxx::__normal_iterator<char*, std::string>,
rpp::pp_output_iterator<std::string> >(bool,
__gnu_cxx::__normal_iterator<char*, std::string>,
__gnu_cxx::__normal_iterator<char*, std::string>,
rpp::pp_output_iterator<std::string>) () from /usr/lib/libapiextractor.so.0.10
#40892 0x00007ffff78d75d6 in __gnu_cxx::__normal_iterator<char*, std::string>
rpp::pp::handle_include<__gnu_cxx::__normal_iterator<char*, std::string>,
rpp::pp_output_iterator<std::string> >(bool,
__gnu_cxx::__normal_iterator<char*, std::string>,
__gnu_cxx::__normal_iterator<char*, std::string>,
rpp::pp_output_iterator<std::string>) () from /usr/lib/libapiextractor.so.0.10
#40893 0x00007ffff78d79bc in char const* rpp::pp::handle_include<char const*,
rpp::pp_output_iterator<std::string> >(bool, char const*, char const*,
rpp::pp_output_iterator<std::string>) () from /usr/lib/libapiextractor.so.0.10
#40894 0x00007ffff78d705b in void rpp::pp::operator()<char const*,
rpp::pp_output_iterator<std::string> >(char const*, char const*,
rpp::pp_output_iterator<std::string>) () from /usr/lib/libapiextractor.so.0.10
#40895 0x00007ffff78d7339 in void
rpp::pp::file<rpp::pp_output_iterator<std::string> >(_IO_FILE*,
rpp::pp_output_iterator<std::string>) ()
   from /usr/lib/libapiextractor.so.0.10
#40896 0x00007ffff78d7ac9 in char const* rpp::pp::handle_include<char const*,
rpp::pp_output_iterator<std::string> >(bool, char const*, char const*,
rpp::pp_output_iterator<std::string>) () from /usr/lib/libapiextractor.so.0.10
#40897 0x00007ffff78d705b in void rpp::pp::operator()<char const*,
rpp::pp_output_iterator<std::string> >(char const*, char const*,
rpp::pp_output_iterator<std::string>) () from /usr/lib/libapiextractor.so.0.10
#40898 0x00007ffff78d7339 in void
rpp::pp::file<rpp::pp_output_iterator<std::string> >(_IO_FILE*,
rpp::pp_output_iterator<std::string>) ()
   from /usr/lib/libapiextractor.so.0.10
#40899 0x00007ffff78d7ac9 in char const* rpp::pp::handle_include<char const*,
rpp::pp_output_iterator<std::string> >(bool, char const*, char const*,
rpp::pp_output_iterator<std::string>) () from /usr/lib/libapiextractor.so.0.10
#40900 0x00007ffff78d705b in void rpp::pp::operator()<char const*,
rpp::pp_output_iterator<std::string> >(char const*, char const*,
rpp::pp_output_iterator<std::string>) () from /usr/lib/libapiextractor.so.0.10
#40901 0x00007ffff78d7339 in void
rpp::pp::file<rpp::pp_output_iterator<std::string> >(_IO_FILE*,
rpp::pp_output_iterator<std::string>) ()
   from /usr/lib/libapiextractor.so.0.10
#40902 0x00007ffff78d73e1 in void
rpp::pp::file<rpp::pp_output_iterator<std::string> >(std::string const&,
rpp::pp_output_iterator<std::string>) () from /usr/lib/libapiextractor.so.0.10
#40903 0x00007ffff78c7180 in preprocess(QString const&, QFile&, QStringList
const&) () from /usr/lib/libapiextractor.so.0.10
#40904 0x00007ffff78c7848 in ApiExtractor::run() () from
/usr/lib/libapiextractor.so.0.10
#40905 0x000000000040a200 in main ()

Additionally I get a ton of warnings like this:

** WARNING unknown directive '#' at /usr/include/boost/preprocessor/cat.hpp:8
** WARNING unknown directive '#' at /usr/include/boost/preprocessor/cat.hpp:9
** WARNING unknown directive '#' at /usr/include/boost/preprocessor/cat.hpp:10
** WARNING unknown directive '#' at /usr/include/boost/preprocessor/cat.hpp:11

before the crash.  I think they don't matter, the boost author was just putting
a "#" at the beginning of every line of the files (for extra beauty, I guess).

Also a few warnings like this:

** WARNING expected ``)'' = 1002
** WARNING expected ``)'' = 1002
** WARNING expected ``)'' = 1002

and some others with 40 instead of 1002.  For those messages it is not clear
where the problem is coming from, since they don't have a filename.

I see a similar behavior when I #include <boost/thread.hpp>, but instead of
crashing it seems to get into a broken state where it doesn't see any more of
my class definitions after that #include.

I know boost pushes hard on the C++ preprocessor, and apiextractor seems to be
essentially duplicating a bunch of the preprocessor's functionality, so it's
not surprising there would be trouble.