[CMake] Finding Python3

[Michael Hertling]

On 07/22/2010 09:18 AM, Alan W. Irwin wrote:
> On 2010-07-22 03:09+0200 Michael Hertling wrote:
> 
>> In summary, my point is: Even if the loops are swapped, we wouldn't get
>> a solution that works well in real-world scenarios so I doubt if it's
>> worth the effort [...].
> 
> Hi Michael:
> 
> I think find issues are a really important topic so I am glad you are
> adding so much to the discussion.
> 
> Although I agree with much of what you say, in this particular case I
> believe your above premise is too general, and you have therefore
> drawn an incorrect conclusion.  PLplot and other software packages
> with CMake-based build systems have run into a number of real-world
> Find issues that would be solved if 10718 were fixed. [...]

Wouldn't they be solved if the find modules were fixed instead of 10718?

> [...] Obviously, this
> fix does not deal with the same-directory case, but at least the fix
> limits find issues to just that case alone, and I believe that
> simplification is well worth having.
> 
> Assuming 10718 gets fixed, then one possibility for dealing with the
> same-directory case is to simply publicize this is a well-known find
> issue with current CMake find modules and leave it at that.  That
> "solution" certainly has the merit of simplicity and only fails for
> the rare case where an older version is desired that resides in the
> same directory as a later version (assuming the NAMES are ordered from
> newest to oldest version).

Particularly in regard to Python, I'm not sure if a solution to the
same-directory case should be dropped just like that. Thanks to the
systematically versioned vital components - interpreter, libraries,
library subdirectory and include directory - Python is predestined
to allow multiple installations under the same prefix. Now, from a
user's point of view, I would greatly appreciate an opportunity to
say FIND_PACKAGE(Python 2.5 EXACT ...), and vice versa, I would be
greatly displeased if this attempt fails, despite of 2.5 installed
and even mentioned after NAMES, because of the mere 2.6 presence.

>> [...] one should
>> prefer to improve the find modules and get rid of those non-equivalent
>> alternatives after the NAMES option, in particular hardcoded version
>> lists, and freshly developed modules should use FIND_PACKAGES()'s
>> version interface right from the beginning.
> 
> This certainly sounds promising for dealing with the same-directory
> case.  However, although the version interface appears in the usual
> documentation, I cannot find a single example of a
> <config-file>Version.cmake file.  Am I missing something or is there
> no practical demonstration of the version interface for any Find
> module included with CMake?

As MW already pointed out, these version files aren't relevant
to the search for Python until GvR switches over to CMake. ;)

> Until there is a practical demonstration of the version interface it
> is hard to be sure this is the solution we should recommend for all
> find modules. Therefore, would you be willing to create a simple
> project demonstrating your idea and share it with this list?
> 
> The simple project I have in mind would consist of a single Python
> find module (the usual boiler plate + three find commands) which did
> essentially nothing but find the (versioned) python interpreter,
> header file directory, and library under the version interface; the
> accompanying file mentioned in the documentation to support the
> version interface; and a single CMakeLists.txt file consisting of ~10
> lines which specified the location of that find module (and version
> interface support file); allowed the user the option of setting the
> python version to anything they liked (e.g., nothing, 2, 2.5, 2.6, 3,
> etc.); and used find_package to find and print out the appropriate
> Python interpreter, header file directory, and library for the
> user-specified version.

Look at CMakeLists.txt and FindPython.cmake in the attachment.

To prevent further references to John Ronald Reuel T.: This finder is
neither fully-featured nor production-ready, and it also doesn't claim
to be the most beautiful piece of code ever written; furthermore, it is
targeted at *nix and most probably won't run on another platform out of
the box. Instead, it's just meant to outline a possible approach how to
use FIND_PACKAGE()'s version interface to locate a Python installation
without relying on hardcoded version numbers or an interpreter which
possibly cannot run on the current system.

Remarks:

- PYTHON_NATIVE indicates whether the interpreter may by invoked.
- Requesting "Python" without version means searching for an
  unversioned interpreter and the highest versioned library unless
  PYTHON_NATIVE is true which means querying the interpreter for its
  accompanying library; the former may possibly result in inconsistent
  interpreter/library combinations.
- Requesting "Python 2" means searching for the highest Python 2 but
  not 3; EXACT doesn't matter here.
- Requesting "Python 2.5" means searching for the highest Python 2 but
  at least 2.5 and not 3.
- Requesting "Python 2.5 EXACT" means searching for the highest Python
  2.5 but not 2.6 or higher or 3.
- Requesting "Python 2.5.4" means searching for the highest Python 2
  but at least 2.5.4 and not 3; without PYTHON_NATIVE, this may fail
  as the interpreter is necessary to check for a three-digit version.
- Requesting "Python 2.5.4 EXACT" means searching for Python 2.5.4;
  without PYTHON_NATIVE, this fails for the same reason as above.
- GET_LIBRARY_PATH() is of general purpose and could be transferred
  to a module of its own, possibly along with a GET_PROGRAM_PATH() etc.
- Components aren't recognized, but this shouldn't be hard to implement.

Regards,

Michael
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CMakeLists.txt
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100802/bf0fdbe0/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: FindPython.cmake
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100802/bf0fdbe0/attachment-0001.asc>