rbtree.py Is Not Automatically Regenerated When A New Header Is Included In rbtree.i

[liangfok]

Problem Definition

When a new header file is included in drake-distro/drake/bindings/swig/rbtree.i, the classes that are defined within this header file do not appear in the automatically-generated drake-distro/drake/bindings/python/pydrake/rbtree.py even after rebuilding drake. Oddly, the new classes' symbols do appear in drake-distro/build/drake/bindings/swig/_rbtree.so, meaning the two are inconsistent. Deleting drake-distro/drake/bindings/python/pydrake/rbtree.py and rebuilding drake does not work because ninja does not believe anything changed (I'm currently assuming make will behave identically).

Workaround

The only workaround I've found is to do a comprehensive nuke:

$ cd drake-distro
$ rm -rf *
$ git reset --hard HEAD
$ mkdir build; cd build
$ cmake .. -G Ninja
$ ninja

I'm wondering whether there's a better way to regenerate the correct rbtree.py without resorting to the comprehensive nuke.

[david-german-tri]

I think @jamiesnape knows more than anyone else about the SWIG mess currently, so he may have some thoughts.

[david-german-tri]

Deleting drake-distro/drake/bindings/python/pydrake/rbtree.py and rebuilding drake does not work because ninja does not believe anything changed (I'm currently assuming make will behave identically).

BTW it might be useful to check this assumption. We've seen some indications recently that if your CMake isn't perfectly crafted, it will produce ninja that ignores file dependencies like this but make that respects them. (See for instance #4303, which isn't a perfect analogue - and which I still don't fully understand - but still.)

[jamiesnape]

There is an issue with the logic, I think. I do not think this one is a general CMake issue, as much as it an unconventional way of using it. You definitely should not have to nuke your whole build. At worst, you would remove the drake build directory and the configure, build, and install stamp files.

[jamiesnape]

The fix is to rewrite the code, which would not take especially long, but it could well be time better spent looking at SWIG alternatives.

[rdeits]

I am almost entirely certain that this error was not present when I developed the swig bindings, which would support the hypothesis that it's not present when using make.