[CMake] Finding Python3

[Michael Wild]

On 23. Jul, 2010, at 18:43 , Branan Purvine-Riley wrote:

> On Fri, Jul 23, 2010 at 12:28 AM, Michael Wild <themiwi at gmail.com> wrote:
>> 
>> 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.
>> 
>> Oh, and another problem. LDLIBRARY on OS X returns
>> 
>> Python.framework/Versions/2.6/Python
>> 
>> Not sure how find_library likes that.
>> 
>> 
>> Michael
>> 
>> 
> 
> * I intentionally left the suffixes on, so it would pass the full path
> of the library to the calling CMake module. That's why I use FIND_FILE
> with NO_DEFAULT_PATH - I'm not trying to search for the library, just
> verifying it exists where Python tells me it should.
> 

Ah, yes. Missed that.

> * I'm aware of the cross-compiling issue. It's on the TODO list, I
> just need to write the library-finding code.
> 
> * I know a couple of people with macs, I'll try to get some time on
> one of them so I can sort out precisely what my code does on mac and
> what needs to be done to make it work correctly. It's hard to verify
> mac support before I push when all I have is windows and linux.
> Hopefully getting the framework is just a matter of some pathname
> manipulation.

It actually should be.

> 
> --Branan


Michael