You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In file included from src/network/bindings/ns3module.cc:1:0:
src/network/bindings/ns3module.h: In member function ‘virtual bool PythonCallbackImpl1::operator()(ns3::Ptrns3::NetDevice, ns3::Ptr, short unsigned int, const ns3::Address&, const ns3::Address&, ns3::NetDevice::PacketType)’:
src/network/bindings/ns3module.h:4944:96: error: ‘PyNs3NetDevice__PythonHelper’ was not declared in this scope
Here is some context on this change. Until now, NetDevice was pure abstract, but the changes proposed in this class add some non-virtual methods and private data.
If I modify NetDevice with some trivial non-virtual methods and private data, pybindgen still works, so it has to do with something about the specific nature of the proposed changes and not generically about moving from pure abstract to abstract.
The compilation is failing in the definition of one of the callbacks:
where the PyNs3NetDevice__PythonHelper does not exist because this is an abstract class still.
In the previous version of the bindings, the if () branch does not exist, and the function moves directly to
wrapper_lookup_iter = PyNs3ObjectBase_wrapper_registry.find((void *) const_cast<ns3::NetDevice *> (ns3::PeekPointer (arg1)));
so what appears to be the problem is that something is triggering pybindgen to include this TypeId check, which is failing due to lack of the PyNs3NetDevice__PythonHelper class.
At this point I'm not clear whether it is a pybindgen issue or not.
The text was updated successfully, but these errors were encountered:
It looks like this is a side-effect of some code generation customisations I did for ns-3. I don't think normal PBG usage is affected.
It happens that we generate some code to support ns-3 callbacks wrappers in advance, before PBG gets a chance to call generate_forward_declarations(), which would invalidate the "helper class" at that point. We generate code thinking we will have a helper class, but PBG changes its mind later on when it finds out the helper class could not be generated (possibly due to some pure virtual method for which we could not generate wrappers). Basically, stupid PBG design decisions, if I were to start from scratch I would do a lot of things differently...
Can you please apply the attached patch to ns-3? Thanks.
I have a question regarding the failure of bindings compilation for some proposed changes to ns-3 NetDevice.
To reproduce:
git clone https://github.com/stavallo/ns-3-dev-git
cd ns-3-dev-git
git checkout -b queue-disc-exp remotes/origin/queue-disc-exp
./waf configure --enable-modules=network --with-pybindgen=/path/to/pybindgen
./waf build
./waf --apiscan=network
./waf build
fails with:
In file included from src/network/bindings/ns3module.cc:1:0:
src/network/bindings/ns3module.h: In member function ‘virtual bool PythonCallbackImpl1::operator()(ns3::Ptrns3::NetDevice, ns3::Ptr, short unsigned int, const ns3::Address&, const ns3::Address&, ns3::NetDevice::PacketType)’:
src/network/bindings/ns3module.h:4944:96: error: ‘PyNs3NetDevice__PythonHelper’ was not declared in this scope
Here is some context on this change. Until now, NetDevice was pure abstract, but the changes proposed in this class add some non-virtual methods and private data.
If I modify NetDevice with some trivial non-virtual methods and private data, pybindgen still works, so it has to do with something about the specific nature of the proposed changes and not generically about moving from pure abstract to abstract.
The compilation is failing in the definition of one of the callbacks:
where the PyNs3NetDevice__PythonHelper does not exist because this is an abstract class still.
In the previous version of the bindings, the if () branch does not exist, and the function moves directly to
wrapper_lookup_iter = PyNs3ObjectBase_wrapper_registry.find((void *) const_cast<ns3::NetDevice *> (ns3::PeekPointer (arg1)));
so what appears to be the problem is that something is triggering pybindgen to include this TypeId check, which is failing due to lack of the PyNs3NetDevice__PythonHelper class.
At this point I'm not clear whether it is a pybindgen issue or not.
The text was updated successfully, but these errors were encountered: