[CMake] Finding Python3

[Branan Purvine-Riley]

On Sunday 18 July 2010 09:15:17 Michael Hertling wrote:
> 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

Those are all good points. I knew there had to be a reason why the simple fix 
hadn't been implemented yet. I've started a new implementation (pushed to my 
git tree, and attached here). It currently just finds the python interpreter, 
getting library information from the interpreter is trivial, but I also need 
to add a fallback when cross-compiling.

Unfortunately, I can't think of a way to get out of using hardcoded version 
lists, since python is often in specific locations (or has a specific executable 
name) based on its version number. I did make the version lists more robust, 
basing them off of FindBoost.cmake. Hopefully this, combined with using the 
interpreter to find the libraries, will help mitigate the problems seen with 
the earlier FindPython* modules.

My implementation allows two different ways to search for Python 3 - either a 
VERSION 3 argument, or setting Python_3_OK to TRUE. I did this because it is 
possible to write programs that are python2.6+ and python3.x compatible, so 
the following:

    set(Python_3_OK TRUE)
    find_package(Python VERSION 2.6)

will work correctly for programs that support Python 2.6+ and Python 3.x.

Programs that just want Python 3 can simply call:

    find_package(Python VERSION 3)

I've verified all the versioning (incuding EXACT) works correctly on Windows 
and Linux with python2.6 and python3.1 installed.

If what I have looks good, I'll add handling for Python_LIBRARIES from the 
python executable and components support. Then I'll look at the cross 
compiling case and set up a secondary library search system.

The most current version of the file is at 
<http://github.com/branan/CMake/blob/python3/Modules/FindPython.cmake>

--Branan