Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly

Subject: Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly
From: Troy D. Straszheim (troy_at_[hidden])
Date: 2009-12-22 08:54:16

Denis Arnaud <denis.arnaud_boost_at_[hidden]> writes:

> 2009/12/21 Troy D. Straszheim <troy_at_[hidden]>
>
>     AFAIK this is the only python module built by boost and nobody has given
>     serious thought to where it should be installed. Â This is a large can of
>     wriggly worms. Â /usr/lib[64]/python2.6/boost does sounds reasonable, the
>     important thing is that it is on the system's PYTHONPATH. Â You'd also
>     need to drop an empty __init__.py into that boost directory.
>
>
[snip]
>
> So, you are right, Troy: except for MPI, only test suites build Python
> extensions.
> Following is the building directive for the MPI Python extension (in libs/mpi/
> src/CMakeLists.txt):
> Â  boost_python_extension(mpi
> Â Â Â  python/collectives.cpp
> Â Â Â  [...]
> Â Â Â  python/py_timer.cpp
>
> Â Â Â  DEPENDS boost_python boost_mpi
> Â Â Â  SHARED_COMPILE_FLAGS "-DBOOST_MPI_DYN_LINK=1 -DBOOST_MPI_PYTHON_DYN_LINK=1
> -DBOOST_PYTHON_DYN_LINK=1"
> Â Â Â  LINK_FLAGS ${MPI_LINK_FLAGS}
> Â Â Â  LINK_LIBS ${MPI_LIBRARIES} ${PYTHON_LIBRARIES})
>
> So, as I understand, we should explicitly link the mpi.so Python extension, not
> only with the MPI libraries, but also with the Boost.MPI ones
> (libboost_mpi.so). We would have to amend the LINK_LIBS directive with
> something like:
> Â Â Â  LINK_LIBS ${MPI_LIBRARIES} ${PYTHON_LIBRARIES} ${BOOST_MPI_LIBRARIES}
>
> But I do not see any such ${BOOST_MPI_LIBRARIES} variable defined. How should
> we do it?
>

What problem are you trying to solve?  If you make with VERBOSE=1 I
believe you will see that boost_mpi is linked already.

> 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?

-t