[CMake] How to install openbabel python bindings by using the new cmake installer (problem selecting a particular python version).

[Hector Martinez-Seara]

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 <mhertling at 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: hseara at gmail.com
Tel: +34656271145
Tel: +358442709253