Writing bindings with the new "built-in" boost::python

Community Build and Deployment
1

We import a build of OpenUSD into our bazel build environment. In order to interoperate with OpenUSD’s boost::python bindings, we sometimes bind our code using boost::python as well, using the boost::python headers and libraries in the distribution. We do it using standard boost::python practice, using the macro BOOST_PYTHON_MODULE.

With 24.11, this macro is no longer available, and the possible equivalent TF_WRAP_MODULE seems to depend on cmake-specific build system support, which we don’t have.

Any guidance? What should we be doing? @sunya ?

2

@Arun The new pxr_boost::python functionally mirrors boost::python but updates the namespace and macro names to distinguish the two. So instead of BOOST_PYTHON_MODULE in boost/python/module.hpp, you should be able to use PXR_BOOST_PYTHON_MODULE in pxr/external/boost/python/module.hp.

2 Likes
3

Gotcha. I’ll try that – thanks!

4

@sunya I have some code that had been using boost::python, which I am now updating to use pxr_python. I don’t use the module macros though, its a bit lower level.

One extra complication is that I need to support older USD runtimes with the same code. I can use the various macros (eg PXR_BOOST_PYTHON_NAMESPACE) to make my code work, but I hit a compile error initially that confused me, which led me to dig into the USD headers more, and I found 3 uses of namespace boost that I wasn’t expecting.

Are these intentional? What effect do they have on a pxr_python enabled build? Should they be protected by the PXR_BOOST_PYTHON_HAS_BOOST_SHARED_PTR conditional that I see in OpenUSD/pxr/external/boost/python/converter/registered.hpp at release · PixarAnimationStudios/OpenUSD · GitHub ?

5

Hey @andrew, those are remnants from our boost-dependent days that need to be cleaned up. AFAIK they should have no effect at all – as a test, I removed them completely and the build had no complaints. I’ll file a follow-up task for this internally.

2 Likes
6

As part of adapting to this change, I’m also needing to have pre-2411 supported with the same code for a short amount of time longer.

Is it ok to use the PXR_USE_INTERNAL_BOOST_PYTHON define in application code to do this, or is there a better, compile-time, indicator I can latch on to?

7

Hi @deadpin, sorry for the late reply, I missed the notification on this thread.

If you need to support pre-24.11 releases in your code, you could check PXR_VERSION instead of PXR_USE_INTERNAL_BOOST_PYTHON. Both should work, but the latter would let you support 24.11 builds using the external boost::python library. PXR_USE_INTERNAL_BOOST_PYTHON will still be defined even after backwards compatibility support for boost::python is removed in a future release.