I recently took another look at boost::python. It was a much better experience than when I first tried boost::python for Glom in 2005, probably because my use of the Python C API in the meantime has helped me understand what boost::python is doing. I have a mostly-done patch to use it in Glom 1.12 (Glom 1.10 will be released soon). This should make the code simpler and much more robust, allowing me to add more Python API to Glom, allowing people to drive more of the Glom UI via scripts.

As a side-effect this will force us to enable C++ exceptions in the Maemo build for Glom 1.12, increasing code size, but that might be less of an issue by then.

I do find the boost::python documentation fragmented and unfocused, spending too much time congratulating itself about its use of various design patterns and generic programming techniques in the implementation, instead of just telling me how to achieve common tasks. It often assumes knowledge of the Python C API, as if it is based on original proposals or internal documentation. Many companies are using boost::python so I’m surprised that none have arranged for more useful documentation to be written. I’d be happy to do it if someone wants to pay for my time.

In fact, boost::python’s API maps closely to the C API, so you probably need to know both, though I hoped that boost::python would make it clearer and more explicit.

However, the people on the boost::python mailing list have been very helpful when the documentation has not been clear or where I have made silly mistakes.

Boost should install pkg-config .pc files

Getting the CFLAGS and LIBS for boost python in your configure.ac is insanely difficult and fragile. There are some .m4 scripts out there, but I can’t get any of them to work. Why on earth don’t they install a .pc file? They can’t all be Windows programmers.

And despite using unstable APIs, they don’t seem to allow parallel installs. For instance, on my Ubuntu Linux system, the headers are directly under /usr/include/ rather than /usr/include/boost-python-1.0/. GNOME gets this stuff right.

The need for parallel installs is even greater for boost::python because there are various possible incompatible configurations, any of which you are likely to find on your system. At the moment you will just get compiler or linker errors (which distro packagers don’t understand) instead of being able to explicitly depend on a specific version with a specific build (which distro packagers could understand).

This will make life difficult for Glom distro packagers, but I think it’s still worth it.