[C++-sig] Advice sought on making a large C++ application a Python extension

Benoit Leveau benoit-l at moving-picture.com
Mon Sep 6 20:08:58 CEST 2010


David Aldrich wrote:
> Hi Ravi
> 
> Thanks for your reply.
> 
>> Yes. PyOGRE or cctbx are excellent exmples of larger projects which use
>> boost.python. You may want to use py++ to automate binding generation to
>> save yourself quite some time.
> 
> Ok, I will look at py++.
py++ is very good for the goal you have in mind, but you should start to get your hands on it
with something small. I recommend that you first try to bind only one of your libraries,
and develop a framework to do that bindng (some classes/scripts that contain py++ code you'll use a
lot, like adding documentation to a function, excluding functions that have warnings, etc.)
Else, you'll end up having a big python script for each library you want to bind, whereas with this approach
you can use the same "binding generator" for all your libraries.

If you write some command line scripts that generate the binding, you can finally - directly from
your Makefile - generate and compile the binding code.

>> No. The python modules can be compiled using regular make. My
>> recommendation
>> is to avoid using bjam, even if it is technically superior, as it is not
>> used
>> widely enough to have the critical mass that other tools (autotools, cmake,
>> scons) have which means that finding help is pretty painful (as there seem
>> to
>> be only a couple of people with knowledge sufficient to answer any non-
>> trivial
>> questions).
> 
> Understood. Though the boost community seems to promote bjam quite hard ;-)
To compile the boost libraries (including boost python), it is indeed best to use bjam
(especially considering that you generally don't have to customize that).
But, then to link your project against these boost libraries, you have no real benefit
of using bjam IMHO.
 
>> These are simply shared libraries (on POSIX). So the linker can read them.
>> Avoid storing the python bindings in the same shared libraries as your
>> core code since the coupling will be hard to undo while gaining nothing.
> 
> So, I should make both normal dll's for the C++ application and .pyd extensions for the Python interface?

Yes, and actually your pyd libraries will link against these dlls, so:
- the pyd files contain only the python-to/from-c++ layer
- whereas your dlls contain your original application code

Cheers,
Benoit


More information about the Cplusplus-sig mailing list