2009/12/22 Troy D. Straszheim <troy@resophonic.com>
What problem are you trying to solve?  If you make with VERBOSE=1 I
believe you will see that boost_mpi is linked already.

I just try to have the mpi.so library linked with the boost_mpi.so library.

The following shows what I get with "make VERBOSE=1":
 Linking CXX shared module ../../../lib/mpi.so
 cd /home/build/dev/packages/BUILD/boost-1.41.0.cmake0/build/libs/mpi/src && /usr/bin/cmake -E cmake_link_script CMakeFiles/mpi-mt-shared.dir/link.txt --verbose=1
 /usr/lib64/ccache/c++  -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wl,-z,noexecstack -Wl,-rpath -Wl,/usr/lib64/mpich2 -shared -Wl,-soname,mpi.so -o ../../../lib/mpi.so CMakeFiles/mpi-mt-shared.dir/python/collectives.cpp.o [...] CMakeFiles/mpi-mt-shared.dir/python/py_timer.cpp.o /usr/lib64/python2.6/config/libpython2.6.so -lpthread -lrt ../../../lib/libboost_python-mt.so.5

So, obviously, mpi.so is linked with the Python (libpython2.6.so in my case) and Boost.Python (libboost_python-mt.so.5) libraries, but not with the boost_mpi.so library!
[Note that I use a soname version of 5, instead of 1.41.0, for compatibility with Fedora 12, where Boost has been delivered with a soname version of 5]

Another way to see the same thing:
 $ ldd ../../../build/lib/mpi.so
        libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0 (0x00007fd9e7eba000)
        [snip]
        libboost_python-mt.so.5 => /usr/lib64/libboost_python-mt.so.5 (0x00007fd9e7845000)

resulting in a lot of missing symbols, e.g.:
 $ ldd -r ../../../build/lib/mpi.so 2>&1 | c++filt | head
 undefined symbol: typeinfo for boost::mpi::exception    (../../../build/lib/mpi.so)


> The other question is: how could we set a distinct installation path for that
> Python extension?
> We could maybe define a CMAKE_PYTEXT_INSTALL_PREFIX variable for that purpose?
 
Yes one could. You could pass NO_INSTALL to add_single_library() and
then call cmake's install() manually on the mpi target.  But it'd be
nice if this were more generally usable. Typically things are more
complicated, e.g. there is associated pure python code (say, __init__.py
and some other stuff) and different modules will want to live in
different subdirectories of the system's site-packages...  should one
just hand this off to python's distutils?  Are there any well-behaved,
cmake-built python bindings in existence?  What do they do?

I'm unfortunately not a Python packaging expert. If time allows, I'll try to look at a few projects (packaged for Fedora) delivering Python extensions. But, in the meantime, I guess that delivering the mpi.so library correctly linked with boost_mpi will be enough. For the rest (__init__.py, etc.), I'll add the needed files manually in the Python site-packages (I speak about the delivery of Boost by the corresponding RPM package).

D.