Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly
2009/12/21 Troy D. Straszheim
> 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.
>
As I understand, the building of Python modules (extensions) is configured
thanks to the boost_python_extension directive within CMakeLists.txt files.
Also, it is then easy to see where such extensions are generated:
$ find . -name '*.txt' -exec grep -Hn "boost_python_extension" {} \;
./libs/python/test/CMakeLists.txt:39:
boost_python_extension(${BPL_EXTENSION_MODULE} ${SRC})
./libs/python/test/CMakeLists.txt:53:
boost_python_extension(${TESTNAME}_ext "${TESTNAME}.cpp")
./libs/python/test/CMakeLists.txt:139:boost_python_extension(builtin_converters_ext
test_builtin_converters.cpp)
./libs/python/test/CMakeLists.txt:146:#
boost_python_extension(overload_resolution test_overload_resolution.cpp)
./libs/python/test/CMakeLists.txt:208:boost_python_extension(map_indexing_suite_ext
./libs/parameter/test/CMakeLists.txt:70:
boost_python_extension(${BPL_EXTENSION_MODULE} ${SRC})
./libs/parameter/test/CMakeLists.txt:84:
boost_python_extension(${TESTNAME}_ext "${TESTNAME}.cpp")
./libs/mpi/src/CMakeLists.txt:54: boost_python_extension(mpi
./tools/build/CMake/selftest_projects/pymodules/src/CMakeLists.txt:10:boost_python_extension(fooext_rel
./tools/build/CMake/selftest_projects/pymodules/src/CMakeLists.txt:20:boost_python_extension(fooext_dbg
./tools/build/CMake/selftest_projects/pymodules/src/CMakeLists.txt:30:boost_python_extension(fooext_default
./tools/build/CMake/selftest_projects/pymodules/src/CMakeLists.txt:42:boost_python_extension(fooext_test_linkflags
./tools/build/CMake/test/libs/d/src/CMakeLists.txt:55:boost_python_extension(doesntbuild
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?
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?
Thanks in advance
Denis
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly
Denis Arnaud writes:
> 2009/12/21 Troy D. Straszheim
>
> 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
___
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly
2009/12/22 Troy D. Straszheim > 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 (0x7fd9e7eba000) [snip] *libboost_python-mt.so.5* => /usr/lib64/libboost_python-mt.so.5 (0x7fd9e7845000) 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. ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
