Closed iMichka closed 8 years ago
Not yet. I hope to get around this soon.
Here is a minimal example that fails on Ubuntu 15.10, gcc 5.2.1, castxml version 0.1-gf1bb3c2, pygccxml 1.7.4, and pyplusplus 1.6.0. Save the attached files and run python test.py
.
The same example also fails on OS X 10.11.5, gcc 6.1.0, castxml 0.1-g8c32543, pygccxml 1.7.4, and pyplusplus 1.6.0 with the same error.
Hi
I had some time to look at this. I could write a test to reproduce the bug, which I pushed to the hotfix/v1.7.6 branch. The travis build for this branch is not failing because it does not test against gcc (this is only done on the develop branch). But I can reproduce the bug locally.
The problem lies in the _M_clone_node
method which is exposed in the xml file. First thing I saw is that no parent is set in pygccxml for this method (decl.parent == None).
Other methods, like for example _M_drop_node
, have a parent (e.g. in this case the class '_Rb_tree<int, std::pair<const int, int>, std::_Select1st<std::pair<const int, int> >, std::less<int>, std::allocator<std::pair<const int, int> > >
)
However the class definition in the xml file lists the _M_clone_node
method (3 times), so _M_clone_node
should have a parent.
_M_clone_node
is defined three times with different argument types, whereas the others like _M_drop_node
are defined only once. This is the only difference I can see for the moment.
I will now investigate how and when the @parent.setter
is called in the declaration_t
class. Once this is understood and fixed, the declaration string creation should work again. I hope it will not take me too long.
Thanks for looking into this. This seems like a painful bug to fix.
This should work now. The bug was that you can pass a struct or class instance without name to a method, and when building the declaration string this was failing. I added a new test for this.
It took me a long time to reproduce. The code in stl_tree.h is hard to follow (this is were _M_clone_node
is defined).
Please test this. If it's ok I'll release the 1.7.6 version after this.
This works! Python binding generation is taking forever, though. On my Ubuntu 15.10 VM it took more than 12 hours to generate the bindings. That's more than an order of magnitude slower than the gccxml-based workflow in the pre-C++11 version of the code. Clang + castxml is somewhere in between in terms of generation time. Nevertheless, the bug is fixed. Thanks!
Great ! I'll make the 1.7.6 release with this fix during the weekend.
I will definitively have a look at the performance problem for v 1.8.0. I had already a look but was not able to solve it. I have maybe an idea how to solve this but this needs some work.
Initially reported here: https://github.com/gccxml/pygccxml/issues/47#issuecomment-215999936 (There are also two xml files in the comment that may be interesting).
Happens with gcc4.9 and gcc5. @mamoll do you have a minimal c++ code example to help setup a test for this ?