On 23. Jul, 2010, at 18:43 , Branan Purvine-Riley wrote: > On Fri, Jul 23, 2010 at 12:28 AM, Michael Wild <them...@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 _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
