Noel and Geoff asked that I discuss my changes at
https://github.com/openbabel/openbabel/pull/33 on the mailing list.
There are two changes.
The first is to ask distutils where to install the python bindings for a
given executable on non-windows systems. Currently, they are installed in
LIBDIR, which is not used by anyone to my knowledge. By asking distutils
for a directory, I seem to always receive the correct location.
On openbabel-discuss, Noel said:
> Note that we don't use Python's distutils to automatically copy the
> files to the standard Python install folder. We used to, through a
> variety of approaches, but I just found it too difficult to maintain
> as it needs to (a) preserve the functionality of "DESTDIR=wherever
> make" which is used by package distributors to stage a build, (b) work
> for local builds without root access and (c) work for system installs.
> The downside is that the user needs to set PYTHONPATH themselves, or
> that they need to copy the files somewhere else for multiple Python
> installations.
With my changes:
(a) for staging environments for packaging
DESTDIR=/tmp/buildroot/ make install
gives
-- Installing:
/tmp/buildroot/usr/local/lib64/python2.7/site-packages/_openbabel.so
-- Installing:
/tmp/buildroot/usr/local/lib64/python2.7/site-packages/openbabel.py
-- Installing:
/tmp/buildroot/usr/local/lib64/python2.7/site-packages/pybel.py
on 64-bit OpenSUSE
and gives
-- Installing: /tmp/buildroot/usr/lib/python2.7/dist-packages/_openbabel.so
-- Installing: /tmp/buildroot/usr/lib/python2.7/dist-packages/openbabel.py
-- Installing: /tmp/buildroot/usr/lib/python2.7/dist-packages/pybel.py
on 64-bit Ubuntu 12.04
Those seem to be working. Note, it even picked up the fact that:
OpenSUSE uses lib64 and site-packages
Ubuntu uses lib and dist-packages
(b) work for local builds without root access
cmake -DPYTHON_BINDINGS=ON -DRUN_SWIG=ON -DCMAKE_INSTALL_PREFIX=~ ..
-- Installing: /home/drhall/lib/python2.7/site-packages/_openbabel.so
-- Installing: /home/drhall/lib/python2.7/site-packages/openbabel.py
-- Installing: /home/drhall/lib/python2.7/site-packages/pybel.py
This corresponds to the user scheme from distutils
http://docs.python.org/2/install/#alternate-installation-the-user-scheme
That seems fairly standard and acceptable.
(c) work for system install
installing without CMAKE_INSTALL_PREFIX or DESTDIR works for a system
install
-- Installing: /usr/local/lib64/python2.7/site-packages/_openbabel.so
-- Installing: /usr/local/lib64/python2.7/site-packages/openbabel.py
-- Installing: /usr/local/lib64/python2.7/site-packages/pybel.py
That is a location that will be found by the system Python and
automatically imported.
This change seems to be acting correctly in all three cases.
The second change is based on this scenario:
(a) you have cmake 2.8.8 or newer installed
(b) the first python in your path is python 2
(c) you have python3-devel libraries installed
This is not out of the question, especially if you use python3 in your
work. Most systems still default to python being python 2
This is what currently happens:
$ cmake -DPYTHON_BINDINGS=ON -DRUN_SWIG=ON ..
--- Removed many lines of output --
-- Found PythonInterp: /usr/bin/python (found version "2.7.3")
-- Found SWIG: /usr/bin/swig (found version "2.0.9")
-- Found SWIG: /usr/bin/swig (found suitable version "2.0.9", minimum
required is "2.0")
-- Found PythonLibs: /usr/lib64/libpython3.3m.so (found version "3.3.0")
-- Python bindings will be compiled
As you can see, the current cmake file gives us python 2.7.3 as our
PythonInterp and python 3.3.0 as our PythonLibs. openbabel will go ahead
with building the bindings like this, but of course they don't work.
My change is to:
(1) First find PythonInterp
(2) Ask cmake what version of python the interpreter is, then have that be
the first version of the library searched for.
After my change:
$ cmake -DPYTHON_BINDINGS=ON -DRUN_SWIG=ON ..
--- Removed many lines of output --
-- Found PythonInterp: /usr/bin/python (found version "2.7.3")
-- Found SWIG: /usr/bin/swig (found version "2.0.9")
-- Found SWIG: /usr/bin/swig (found suitable version "2.0.9", minimum
required is "2.0")
-- Found PythonLibs: /usr/lib64/libpython2.7.so (found version "2.7.3")
-- Python bindings will be compiled
Works beautifully. As a side note, this also allows the user to just
specify the python executable they want to use and cmake will frequently do
the right thing.
As an example (if using cmake <= 2.8.7 )
Before my change:
$ cmake -DPYTHON_BINDINGS=ON -DRUN_SWIG=ON
-DPYTHON_EXECUTABLE=/usr/bin/python3 ..
--- Removed many lines of output --
-- Found PythonInterp: /usr/bin/python3 (found version "3.2.3")
-- Found SWIG: /usr/bin/swig2.0 (found version "2.0.4")
-- Found SWIG: /usr/bin/swig2.0 (found suitable version "2.0.4", required
is "2.0")
-- Found PythonLibs: /usr/lib/libpython2.7.so
-- Python bindings will be compiled
After my change:
$ cmake -DPYTHON_BINDINGS=ON -DRUN_SWIG=ON
-DPYTHON_EXECUTABLE=/usr/bin/python3 ..
--- Removed many lines of output --
-- Found PythonInterp: /usr/bin/python3 (found version "3.2.3")
-- Found SWIG: /usr/bin/swig2.0 (found version "2.0.4")
-- Found SWIG: /usr/bin/swig2.0 (found suitable version "2.0.4", required
is "2.0")
-- Found PythonLibs: /usr/lib/python3.2/config/libpython3.2.so
-- Python bindings will be compiled
Before my change, saying you wanted python3 , when using cmake <= 2.8.7,
still gave you python2 libraries. You would then need to search and find
the python3 libraries and include directories on your system to set the
correct variables. After my change, cmake finds them for you (which is kind
of the point of using cmake, right?).
Let me know if you have any questions or see any problems with these
changes.
-David
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel
