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
minimalShibokenBoostInclude.tar.gz
Description: GNU Zip compressed data
_______________________________________________ PySide mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/pyside
