[CMake] Finding Python3

[Michael Hertling]

On 07/18/2010 06:50 AM, Branan Riley wrote:
> I've mad a very cursory effort to add Python 3 support to CMake. All
> I've done so far is take FindPythonLibs and FindPythonInterp, and
> change the variable names and the python versions. It doesn't yet have
> framework support on Mac, as I have no idea how to specify a Python 3
> framework. Besides that, the code should probably be adjusted so it's
> not duplicated across two modules - a FindPythonLibsCommon.cmake file
> or something that does all the "hard" work.
> 
> I'm making this available now so people can play with it and give
> feedback. I'll clean up the code and get another message out when I
> think it's in a state it can actually be merged into the main CMake
> git tree.
> 
> For now, my work is in a clone on github at
> http://github.com/branan/CMake/tree/python3 . You can add my work as a
> tracking branch to a checkout of the main CMake git tree with the
> following commands:
> 
> git remote add -t python3 branan git://github.com/branan/CMake.git
> git fetch branan
> git checkout -b python3 branan/python3

After having taken a look at FindPython3{Interp,Libs}.cmake, I would
recommend strongly against hardcoding version numbers in find modules.
There has already been discussions revealing serious drawbacks of this
habit, e.g. <http://www.mail-archive.com/cmake@cmake.org/msg28878.html>.
Moreover, FIND_PACKAGE() supports the specification of a version, and I
wonder why this feature is hardly used in such cases, in particular for
new modules. Furthermore, your approach probably suffers from the same
shortcoming as the current FindPython{Interp,Libs}.cmake: They can not
guarantee to deliver consistent interpreter/libraries combinations, cf.
<http://www.mail-archive.com/cmake@cmake.org/msg27324.html>.

What would be really needed is a comprehensive FindPython.cmake, see
<http://www.mail-archive.com/cmake@cmake.org/msg27382.html>, which
addresses these issues entirely, i.e. version support and version
consistency and the question if the interpreter may be invoked to
gather information about the specific python installation, cf.
<http://public.kitware.com/Bug/view.php?id=2257#c11766>. See
<http://www.mail-archive.com/cmake@cmake.org/msg29701.html>
for my basic suggestions w.r.t. FindPython.cmake, in short:

- A version specification through FIND_PACKAGE() is respected.
- At least, two components "interpreter" and "libraries", and if both
  are requested they must be consistent with regard to their versions.
- An external flag PYTHON_NATIVE indicates whether the interpreter may
  be invoked as this is the most secure and most elegant way to learn
  the location of the interpreter's belonging libraries but can't be
  done unconditionally, OTOH, for known reasons. So, it's up to the
  user if the interpreter may be run within FindPython.cmake.

IMO, the transition from Python 2 to 3 is a great occasion to tackle
the problems of the appropriate find modules and for the emergence
of FindPython.cmake.

Regards,

Michael