Hi all, Thank you for your help. I have set PYTHON_EXECUTABLE, PYTHON_INCLUDE_DIR and PYTHON_LIBRARY variables to appropriate values to Python 3.1. Now indeed the compilation works. I'm not an expert in cmake so I am afraid I can say little about changing cmake behavior, but thank you all for your help.
By the way, YES, openbabel bindings work with Python 3 although they might be some minor problems. Thanks, Hector On 17 November 2010 06:54, Michael Hertling <mhertl...@online.de> wrote: > On 11/13/2010 03:08 PM, Marcus D. Hanwell wrote: >> On Nov 13, 2010, at 8:57 AM, Michael Hertling wrote: >> >>> On 11/12/2010 02:13 PM, Hector Martinez-Seara wrote: >>>> Dear all, >>>> I'm trying to install openbabel in linux which in its last version >>>> (2.3.0) uses cmake installer. I haven't been able to compile it with >>>> biddings with python 3.1 when using the -DPYTHON_BINDINGS=ON option. I >>>> have python 2.7 and 3.1 installed in my system and the python command >>>> points to python 3.1. Still cmake only select python 2.7 despite it is >>>> not set as preferred in my system in any way. I have made a small >>>> search and I have seen that there is a lot of troubles selecting >>>> python 3 with cmake. Most of the information was very technical and >>>> honestly I'm not sure if there was any solution at the end. >>> >>> AFAIK, the FindPython{Interp,Libs}.cmake modules are currently not >>> capable to find Python 3, so you should focus on a manual approach >>> at the moment, see below. With the scheduling of issue 8396 for the >>> 2.8.4 roadmap, there's a perpective for the availability of version- >>> or pattern-aware find functions, so maybe, it is possible to improve >>> the find modules w.r.t. version selection in the near or medium term. >> >> This is certainly something I would like to address before the 2.8.4 >> release, but as you said there is no Python 3 awareness right now in the >> find modules. Do the Open Babel Python modules work in Python 3? I work on >> that project, and was not aware that Python 3 support was there, but do not >> work much on the bindings. > > On occasion of Hector's inquiry, I've just taken a look at Open Babel's > CMakeLists.txt files to see how they could possibly be made not search > for a Python 2 installation, but I don't know if it generally works > with Python 3. Perhaps, Hector can provide some information. > >>>> My question is rather easy: >>>> a) Is there any way to force a specific python version (3.1) from the >>>> cmake command line? >>> >>> You might try to set the PYTHON_EXECUTABLE, PYTHON_INCLUDE_DIR and >>> PYTHON_LIBRARY variables to appropriate values for your Python 3.1 >>> installation on the command line, i.e. by use of the -D option or >>> -C along with a prepared script. AFAICS, defining these variables >>> makes the FindPython{Interp,Libs}.cmake modules not look for the >>> interpreter, the include directory and the library by themselves, >>> so you possibly get by without any further modifications, but I >>> have not yet tested this with Open Babel. >>> >>>> or b) Is there variable which I could export, e.g. CC=gcc4.5, to force >>>> python to select the python version I want? >>> >>> None I'm aware of, but - as stated above - there're some undertakings >>> in the near future that might result in a comprehensive and flexible >>> FindPython.cmake module which receives the requested version through >>> FIND_PACKAGE()'s version parameter, including version 3. >>> >> That would certainly be the ideal solution. > > Yes, absolutely, and I'm hopeful that addressing 8396 will pave the > way for this and related concerns. My vision of the objectives are: > > - Instead of just considering FIND_LIBRARY(), one should enhance all > find functions, i.e. FIND_{LIBRARY,PROGRAM,FILE,PATH}(), as James > Bigler has proposed in issue 10856. In particular for Python, one > needs improved FIND_PROGRAM() and FIND_PATH() functions to search > for the versioned interpreter executables and module directories. > - Instead of implementing support for version selection, one should > add general regex pattern matching as proposed in 10856, too. IMO, > pattern matching does suit much better to the find functions than > version selection, is universally useful on its own and has been > requested several times before. > - Pattern-aware find functions should just return a list of matching > candidates whereas the selection of a specific version may be done > by a function implemented in CMake's scripting language, and this > function might use the VERSION_EQUAL/VERSION_GREATER/VERSION_LESS/ > VERSION_GREATER_OR_EQUAL/VERSION LESS_OR_EQUAL parameters proposed > by Philip Lowman for FIND_LIBRARY(). > - The enhanced find functions should be used along with that version > selection function to write a FindPython.cmake which makes use of > FIND_PACKAGE()'s version specification facility and is capable to > handle Python 2 and 3 in an equal manner. > - Finally, this advancement should be used to improve certain find > modules currently containing hardcoded version numbers, e.g. the > Tcl/Tk ones or FindPNG.cmake. Hence, the FIND_PACKAGE() version > parameter could be used to select a specific version, and those > modules' related need of repetitive maintenance vanishes. By > the way, issue 10718 would most probably become obsolete. > > Of course, I'd be interested in opinions and comments on this topic. > > Regards, > > Michael > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > -- Hector Martínez-Seara Monné mail: hse...@gmail.com Tel: +34656271145 Tel: +358442709253 _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake