On Thursday, January 06, 2011 9:23 AM, Geoffrey Hutchison wrote:
>On Jan 6, 2011, at 9:00 AM, Konstantin Tokarev wrote:
>
>> Isn't it better to load Python module manually from OB prefix? Any Python
>> script or application using libpython can load modules from arbitrary
>> locations. Also, environment variables may be used to extend module search
>> path
>
>No. Then any Python script or application will need to know where OB has
>installed the Python module. That presents a chicken-and-egg problem -- how do
>you tell the Python script where to find openbabel.py without something
>installed in the standard Python module search path.
>
>Python distutils makes this easy -- the "issue" here in the bug report is that
>there's currently a mismatch between CMake and distutils IMHO.
>
>John's suggestion to use --root is a good one.
The following patch against 2.3.0 does the job for me, using --root. It does
not address Win32 (which does not appear to install via distutils anyway), and
I'm not confident that it is right for all the relevant CMake configurations,
but it can at least serve as a proof of concept:
----
diff -Naur openbabel-2.3.0/scripts/CMakeLists.txt
openbabel-2.3.0-mod/scripts/CMakeLists.txt
--- openbabel-2.3.0/scripts/CMakeLists.txt 2010-10-25 12:37:42.000000000
-0500
+++ openbabel-2.3.0-mod/scripts/CMakeLists.txt 2011-01-06 09:13:14.000000000
-0600
@@ -84,12 +84,12 @@
VERBATIM)
if (PYTHON_PREFIX)
- install(CODE "execute_process(COMMAND ${PYTHON_EXECUTABLE}
${openbabel_SOURCE_DIR}/scripts/python/setup.py install
--prefix=${PYTHON_PREFIX} WORKING_DIRECTORY ${openbabel_BINARY_DIR}/scripts)")
+ install(CODE "execute_process(COMMAND ${PYTHON_EXECUTABLE}
${openbabel_SOURCE_DIR}/scripts/python/setup.py install --root=\$ENV{DESTDIR}/
--prefix=${PYTHON_PREFIX} WORKING_DIRECTORY ${openbabel_BINARY_DIR}/scripts)")
else (PYTHON_PREFIX)
if (${CMAKE_INSTALL_PREFIX} STREQUAL "/usr/local")
- install(CODE "execute_process(COMMAND ${PYTHON_EXECUTABLE}
${openbabel_SOURCE_DIR}/scripts/python/setup.py install WORKING_DIRECTORY
${openbabel_BINARY_DIR}/scripts)")
+ install(CODE "execute_process(COMMAND ${PYTHON_EXECUTABLE}
${openbabel_SOURCE_DIR}/scripts/python/setup.py install --root=\$ENV{DESTDIR}/
WORKING_DIRECTORY ${openbabel_BINARY_DIR}/scripts)")
else (${CMAKE_INSTALL_PREFIX} STREQUAL "/usr/local")
- install(CODE "execute_process(COMMAND ${PYTHON_EXECUTABLE}
${openbabel_SOURCE_DIR}/scripts/python/setup.py install
--prefix=${CMAKE_INSTALL_PREFIX} WORKING_DIRECTORY
${openbabel_BINARY_DIR}/scripts)")
+ install(CODE "execute_process(COMMAND ${PYTHON_EXECUTABLE}
${openbabel_SOURCE_DIR}/scripts/python/setup.py install --root=\$ENV{DESTDIR}/
--prefix=${CMAKE_INSTALL_PREFIX} WORKING_DIRECTORY
${openbabel_BINARY_DIR}/scripts)")
endif (${CMAKE_INSTALL_PREFIX} STREQUAL "/usr/local")
endif (PYTHON_PREFIX)
----
Also, I tested whether specifying -DPYTHON_PREFIX to CMake could do the job.
It does (see below), with these caveats:
1) I must specify the staging area location separately for the Python extension
(via PYTHON_PREFIX) and for the main build (via DESTDIR)
2) I must specify one at configuration time, and the other at build time.
That's sufficient for me, but it might be inconvenient for others who don't
want to reconfigure in order to install to a different staging area. (I'm not
sure any such others actually exist.)
3) The needed configuration-time value and build-time value are related, but
not identical, because the PYTHON_PREFIX must include the default or explicit
CMAKE_INSTALL_PREFIX. For example:
cmake ../openbabel-2.3.0 -DCMAKE_INSTALL_PREFIX=/usr -DPYTHON_BINDINGS=ON
-DPYTHON_PREFIX=/tmp/openbabel/usr
make
make install DESTDIR=/tmp/openbabel
4) Although the PYTHON_PREFIX approach appears to yield the build and
installation that I want, it leaves OpenBabel's build system not conforming to
the CMake norm (that DESTDIR alone does the right thing).
Regards,
John
--
John C. Bollinger, Ph.D.
Department of Structural Biology
St. Jude Children's Research Hospital
Email Disclaimer: www.stjude.org/emaildisclaimer
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel
