There are some problems that you can only really solve, let alone understand, by diving into code. Lucky enough the Open Source movement has spread like wildfire these days, also for developer tools. So besides that it’s fun and very educating to read someone else’s source code, in come cases it’s also really, really helpful to find out how a program is doing its tricks internally to really understand how to best use it. In particular this problem case that I’ve been investigating including a combination of SCons, SWIG and Python.

It’s a pretty straightforward setup. You’ve got this C++ library which you want to export to Python. You’ve already setup an interface to Lua, using SWIG. Now the cool thing about SWIG [1] is, that it’s really easy to export the same interface to different scripting languages, so you want to use SWIG’s power to use your existing setup and extend that from Lua to Python as well. You take your existing .i file, divide it up into two separate files, a general one and a Lua specific one. Say common.i and lua.i where you include common.i in lua.i. Then you can create your new python.i with the Python specific instructions for SWIG, again including common.i. Problem solved.

Well, not if you’re using SCons as your build tool and you put the %module statement in common.i. That does work for Lua, but for Python strange things will happen with SCons’ build dependencies on the .py wrapper file generated by SWIG. I had to go all the way into SCons’ Tool/swig.py to find out what the problem was. While SCons scans for %module statements, which, if found SCons uses to define the .py file build dependencies for Python extensions, %include statements aren’t honored as such. That’s when I undestood that the problem was my Python specific python.i which didn’t have a %module statement! I put that into common.i, reusing it for Lua and Python, thinking that would be ok. However, that setup will mislead SCons to thinking that there are no %module statements at all. So build dependencies will be incorrect, leading to build errors.

Lesson learned: when using SCons, always put the %module statements for SWIG in the .i file that is used to directly generate the scripting language extension from.