[CMake] Various problems deploying a python module

[Michael Hertling]

On 06/25/2010 04:11 PM, Janosch Peters wrote:
> On 2010-06-25 15:45:37 +0200, Michael Hertling said:
> 
>> On 06/25/2010 03:17 PM, Janosch Peters wrote:
>>> On 2010-06-21 07:01:36 +0200, Michael Hertling said:
>>>
>>>> 8d87d12
>>>
>>> What's that? Leet speak?
>>
>> No, these are the first seven and sufficiently unambiguous digits of
>> the SHA-1 sum of the commit in CMake's Git repository that removes
>> the framework related lines from FindPythonLibs.cmake
> 
> Ok. But the python dilemma still remains:
> 
> 1. FindPythonInterp and FindPythonLibs might still produce inconsistent 
> results (e.g. libs and interpreter of different python versions)
> 2. AFAIK you cannot specify a specific python version you which to include/link
> 
> I think someone on the list suggested to merge both modules into one, 
> which would help making the results consistent. Is this (or any other 
> solution) on your todo list?

Not on mine - I don't feel sufficiently experienced w.r.t. python, but
when thinking about a combined FindPython.cmake, remind the following:

<http://public.kitware.com/Bug/view.php?id=2257>, note #11766
<http://www.mail-archive.com/cmake@cmake.org/msg27382.html>

Therefore, my thoughts about a FindPython.cmake are:

1) FindPython.cmake uses FIND_PACKAGE()'s COMPONENTS option and
   respects a specified version.
2) There're at least the components "interpreter" and "libraries",
   and possibly more for modules.
3) Requesting no components at all means requesting "interpreter"
   and "libraries".
4) Requesting "interpreter" and "libraries" means requesting the
   libraries accompanying the requested interpreter.
5) Requesting solely "libraries" means looking for the libraries
   without referring to an interpreter.

One of the first apparent problems is how to learn the version when
none is specified explicitly since it is necessary to look for the
libraries. My suggestion is to provide a variable PYTHON_NATIVE to
indicate an interpreter's executability, so the latter can be used
to figure out the whole library stuff. Otherwise, one could try to
extract the version from the interpreter's name, or try to find an
unambiguous library directory. In summary, this may be roughly
pseudo-coded as:

IF(Python_FIND_COMPONENTS is empty)
    SET(Python_FIND_COMPONENTS "interpreter" "libraries")
ENDIF()

IF(Python_FIND_COMPONENTS contains "interpreter")
    # Search an interpreter and respect Python_FIND_VERSION et al.
ENDIF()

IF(Python_FIND_COMPONENTS contains "libraries")
    IF(Python_FIND_COMPONENTS contains "interpreter")
        # User requested interpreter and libraries, so the latters must
        # belong to the former; one may be guided by the already found
        # interpreter, but think whether and when you execute it:
        IF(PYTHON_NATIVE)
            # Run the interpreter to locate the associated libraries.
        ELSEIF(Python_FIND_VERSION)
            # Search libraries of the requested version.
        ELSE()
            # Try to extract the version from the interpreter's name,
            # e.g. "python2.6", or as a last resort, try to find a
            # single and, thus, unambiguous library directory.
        ENDIF()
    ELSE()
        # User requested solely the libraries, so don't rely on an
        # interpreter being available; search the libraries as
        # usual and respect Python_FIND_VERSION et al.
    ENDIF()
ENDIF()

So, the user could issue, e.g.,

SET(PYTHON_NATIVE TRUE)
FIND_PACKAGE(Python)

to get a consistent native interpreter/libraries combination, or

FIND_PACKAGE(Python 2.6 COMPONENTS interpreter libraries)

to get a consistent 2.6 interpreter/libraries combination, or

FIND_PACKAGE(Python 2.6 COMPONENTS interpreter)
FIND_PACKAGE(Python 2.6 COMPONENTS libraries)

to get a certain 2.6 interpreter and certain 2.6 libraries, or

FIND_PACKAGE(Python 2.5 COMPONENTS interpreter)
FIND_PACKAGE(Python 2.4 COMPONENTS libraries)

to get the 2.5 interpreter and the 2.4 libraries.

Anyway, one should not take it too lightly; IMO, writing a fully
featured, reliable and consistent FindPython.cmake is rather a
nontrivial task.

Regards,

Michael