Ok - looking back to a thread in Dec 2011 ultimately the problem was that I could not figure out how to ask distutils for the appropriate location of the site-packages folder, so I had to move away from this approach. You seem to have figured it out - nice work.
Merge away, Geoff, if you're happy. - Noel On 22 October 2013 17:09, Noel O'Boyle <baoille...@gmail.com> wrote: > That looks good - I was just a bit worried that one of these > combinations would not work. Let me go back through my old emails to > the list about this problem and see whether this covers all the cases. > I think it does though. > > - Noel > > On 22 October 2013 16:52, David Hall <li...@cowsandmilk.net> wrote: >> 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 >> ------------------------------------------------------------------------------ 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
