[CMake] Finding Python3

[Michael Wild]

On 23. Jul, 2010, at 8:59 , Branan Purvine-Riley wrote:

> On Sunday 18 July 2010 12:07:43 you wrote:
>> 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
> 
> I've pushed to my repo (and attached here) a FindPython.cmake that first 
> locates a python 2 or 3 interpreter, then finds the library/header information 
> from that interpreter. It uses distutils to get the include and library path 
> names. I'm not sure my library implementation is the best way to do it - I 
> didn't see a shortcut function in distutils, but I may have missed something 
> somewhere.
> 
> I still need to add some sort of PYTHON_ROOT variable for custom builds of 
> python that are in a weird place, a fallback library search when cross-
> compilng, and COMPONENTS support.
> 
> Some sort of wrapper around FIND_PROGRAM to make it more robust might be 
> useful if a clear set of requirements can be written - it seems everyone who's 
> chimed in on that debate has different ideas of what's broken and what should 
> be fixed, so for now I'm just going to leave it like it is. It's still a good 
> improvement over the previous FindPython* modules.
> 
> --Branan

Two problems:

* remove prefixes and suffixes from _PYTHON_LIBRARY_NAME (e.g. on OS X it is set to libpython2.6.a)
* when cross-compiling you can't invoke the python executable.


Michael