[PySide] Shiboken - Segmentation fault with boost headers and shiboken include-paths

[Yann Lanthony]

Hi list,

I am facing an issue while trying to bind a class that includes some boost
headers. I am sorry for the long email, but it’s actually a 2 in 1
question. I am joining a minimal project that reproduces the bug, which
structure is :

Foo.h                      ->  my class header
typesystem.xml     ->  my typesystem file

My config :
Qt 4.8.1 (also tested on 4.7.2 and 4.7.4)
Boost 1.49 (also tested on 1.48)
PySide 1.1.1
Linux & Windows

I have a class, Foo, and Foo.h includes <boost/utility/result_of.hpp>. I’ve
included this precise file since I’ve noticed that it was at the origin of
the segmentation fault in my original project. My typesystem file only
contains this class as an object-type.

When I launch shiboken ( shiboken Foo.h typesystem.xml ), I get a lot of
warnings of this type : ** WARNING unknown directive '#', due to boost
inner includes. After some search, I’ve found out these warnings were
corresponding to this bugfix :
1086<http://bugs.pyside.org/show_bug.cgi?id=1086>generatorrunner
segfault processing #include. But with this boost header
and some others (<boost/signal.hpp>), I still get a segmentation fault in
the end, or incorrect parsing ending up with shiboken telling me that my
class Foo is not defined (for example with <boost/utility.hpp>).

This was the first part of my problem. The strange thing was that this
problem appeared on Linux but not on Windows. The reason was actually quite
simple. I looked at the code of apiextractor.cpp and found this :

preprocess.push_include_path(".");
foreach (QString include, includes)

preprocess.push_include_path(QDir::convertSeparators(include).toStdString());
preprocess.push_include_path("/usr/include");

So in every cases, the current working directory and “/usr/include” are
added to the include paths used by shiboken.

Since “/usr/include” has no meaning on Windows, the only include paths that
are used are the ones defined by the user with the include-paths parameter
of the shiboken command line. If boost include directory is not explicitly
given, boost headers are not found so not parsed. On Linux, boost headers
are found in “/usr/include” so they are parsed.

So my real question is : considering that the class I want to bind in
python is using boost only for private members that I don’t want to expose,
do I really need boost headers to be parsed ?

It’s actually working great on Windows even if they are not, but it doesn’t
seem possible to avoid that on Linux due to this automatic addition of
“/usr/include”. I am maybe missing something here, but if I am not, it
would be great to have an option to precise we don’t want to search inside
standard include directories (like in gcc with the -nostdinc option). Or
alternatively and less radical, a way to define headers we want to exclude
from the parsing process ?

Thanks in advance,
Yann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/pyside/attachments/20120610/b74677bc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minimalShibokenBoostInclude.tar.gz
Type: application/x-gzip
Size: 397 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/pyside/attachments/20120610/b74677bc/attachment.bin>