Building Python with CMake
Hi,
as I wrote in my previous email, I'm currently porting Python to some more unusual platforms, namely to a super computer (http://www.research.ibm.com/bluegene/) and a tiny embedded operating system (http://ecos.sourceware.org), which have more or less surprisingly quite similar properties.
To do this, I added CMake files to Python, in order to use CMake to cross compile Python to these platforms. CMake (http://www.cmake.org) is a buildsystem in scope similar to autotools, but it's just one tool (instead of a collection of tools) and it support Windows and the MS compilers as first class citizens, i.e. it can not only generate Makefiles, but also project files for the various versions of Visual Studio, and also for XCode.
Attached you can find the files I had to add to get this working. With these CMake files I was able to build python for eCos, BlueGene, Linux and Windows (with Visual Studio 2003, but here I simply reused the existing pyconfig.h, because I didn't want to spend to much time with this). So for Linux the configure checks should be already quite good and almost complete, for eCos and BlueGene they also work (both are UNIX-like), for Windows there is probably some tweaking required.
So if anybody is interested in trying to use CMake for Python, you can find the files attached. Version 2.4.5 of CMake or newer is required.
I guess I should mention that I'm doing this currently with the released Python 2.5.1.
Bye Alex
2007/7/13, Alexander Neundorf alex.neundorf@kitware.com:
as I wrote in my previous email, I'm currently porting Python to some more unusual platforms, namely to a super computer (http://www.research.ibm.com/bluegene/) and a tiny embedded operating system (http://ecos.sourceware.org), which have more or less surprisingly quite similar properties.
Sorry, missed the previous mail. Have two questions for you:
- Why?
- Do you know if there're plans for support this two platforms beyond this porting?
Thank you!!
Regards,
On Friday 13 July 2007 14:53, you wrote:
2007/7/13, Alexander Neundorf alex.neundorf@kitware.com:
as I wrote in my previous email, I'm currently porting Python to some more unusual platforms, namely to a super computer (http://www.research.ibm.com/bluegene/) and a tiny embedded operating system (http://ecos.sourceware.org), which have more or less surprisingly quite similar properties.
Sorry, missed the previous mail. Have two questions for you:
- Why?
Why porting or why using cmake ? Porting because of VTK (http://www.vtk.org), cmake because it has really good support for cross compiling (cvs version of cmake). And it has the nice side effect that the manually maintained MSVC project files would not be required anymore.
- Do you know if there're plans for support this two platforms beyond
this porting?
BlueGene is for running VTK on it, and this will be supported for the coming years. eCos was for testing the cross compile, since this is easier to work with than with BlueGene. I don't know if there will be users for Python on eCos, but then again I didn't have to change anything to get it working on eCos, the configure checks did it all.
Bye Alex
On 13/07/2007 20.53, Facundo Batista wrote:
as I wrote in my previous email, I'm currently porting Python to some more unusual platforms, namely to a super computer (http://www.research.ibm.com/bluegene/) and a tiny embedded operating system (http://ecos.sourceware.org), which have more or less surprisingly quite similar properties.
Sorry, missed the previous mail. Have two questions for you:
- Why?
Because it would be a single unified build system instead of having two build systems like we have one (UNIX and Windows).
Also, it would be much easier to maintain because Visual Studio projects are generated from a simple description, while right now if you want to change something you need to go through the hassle of defining it within the Visual Studio GUI.
Consider for instance if you want to change the Windows build so that a builtin module is compiled as an external .pyd instead. Right now, you need to go through the hassle of manually defining a new project, setting all the include/libraries dependencies correctly, ecc. ecc. With CMake or a similar tool, it would be a matter of a couple of textual line changes.
[ I'll also remember that "ease of maintanance for developers" is the #1 reason for having a 2.1Mb python25.dll under Windows, which I would really love to reduce. ]
On Friday 13 July 2007 16:11, Giovanni Bajo wrote: ...
Because it would be a single unified build system instead of having two build systems like we have one (UNIX and Windows).
Also, it would be much easier to maintain because Visual Studio projects are generated from a simple description, while right now if you want to change something you need to go through the hassle of defining it within the Visual Studio GUI.
Consider for instance if you want to change the Windows build so that a builtin module is compiled as an external .pyd instead. Right now, you need to go through the hassle of manually defining a new project, setting all the include/libraries dependencies correctly, ecc. ecc. With CMake or a similar tool, it would be a matter of a couple of textual line changes.
[ I'll also remember that "ease of maintanance for developers" is the #1 reason for having a 2.1Mb python25.dll under Windows, which I would really love to reduce. ]
I thought I'll keep you updated, so:
attached you can find the current cmake files I use for Python 2.5.1. They work for eCos, Linux, BlueGene and Windows (which doesn't mean everything is supported or installed, but they create working python interpreters and libs and install the most required files).
Compared to the first version they now contain more install rules, the platform path is not hardcoded anymore and it contains a basic setup for creating source and binary packages (tgz, Debian, Nullsoft installer, PackageMaker depending on your cmake version).
Bye Alex
On Friday 13 July 2007 16:11, Giovanni Bajo wrote:
On 13/07/2007 20.53, Facundo Batista wrote:
as I wrote in my previous email, I'm currently porting Python to some more unusual platforms, namely to a super computer (http://www.research.ibm.com/bluegene/) and a tiny embedded operating system (http://ecos.sourceware.org), which have more or less surprisingly quite similar properties.
Sorry, missed the previous mail. Have two questions for you:
- Why?
Because it would be a single unified build system instead of having two build systems like we have one (UNIX and Windows).
Also, it would be much easier to maintain because Visual Studio projects are generated from a simple description, while right now if you want to change something you need to go through the hassle of defining it within the Visual Studio GUI.
Consider for instance if you want to change the Windows build so that a builtin module is compiled as an external .pyd instead. Right now, you need to go through the hassle of manually defining a new project, setting all the include/libraries dependencies correctly, ecc. ecc. With CMake or a similar tool, it would be a matter of a couple of textual line changes.
[ I'll also remember that "ease of maintanance for developers" is the #1 reason for having a 2.1Mb python25.dll under Windows, which I would really love to reduce. ]
The cmake files for building python are now in a cvs repository: http://www.cmake.org/cgi-bin/viewcvs.cgi/Utilities/CMakeBuildForPython/?root...
This is inside the ParaView3 repository: http://www.paraview.org/New/download.html
I used them today to build Python from svn trunk.
I'll add some documentation how to use them, how to get them and what works and what doesn't work tomorrow.
Bye Alex
Hi,
On Thursday 30 August 2007 16:28, Alexander Neundorf wrote: ...
The cmake files for building python are now in a cvs repository: http://www.cmake.org/cgi-bin/viewcvs.cgi/Utilities/CMakeBuildForPython/?roo t=ParaView3
This is inside the ParaView3 repository: http://www.paraview.org/New/download.html
I used them today to build Python from svn trunk.
I'll add some documentation how to use them, how to get them and what works and what doesn't work tomorrow.
Ok, it took a bit longer. The wiki page is here: http://paraview.org/ParaView3/index.php/BuildingPythonWithCMake
With the cmake files from cvs you can build Python svn, which will become Python 2.6. It use it for Linux, IBM BlueGene/L and Cray Xt3 (in both cases for the compute nodes, not the front end nodes).
It works also for Windows, but I didn't take the time to check that all the configure checks deliver the correct results, so I just reused the premade pyconfig.h there.
Most modules are built now. For every module you can select whether to build it statically or dynamically or not at all. Source and binary packages can be created using "make packages".
These files don't conflict with any files in Python svn, so if somebody is interested adding them to Python svn shouldn't cause any problems.
Bye Alex
P.S. due to moving I'll be mainly offline in the next weeks
On 9/20/07, Alexander Neundorf alex.neundorf@kitware.com wrote:
On Thursday 30 August 2007 16:28, Alexander Neundorf wrote: ...
The cmake files for building python are now in a cvs repository: http://www.cmake.org/cgi-bin/viewcvs.cgi/Utilities/CMakeBuildForPython/?roo t=ParaView3
Thanks for your work on this! That page seems to require a login. Any chance you could post it to something like::
http://wiki.python.org/moin/BuildingPythonWithCMake
STeVe
On Thursday 20 September 2007 16:58, Steven Bethard wrote:
On 9/20/07, Alexander Neundorf alex.neundorf@kitware.com wrote:
On Thursday 30 August 2007 16:28, Alexander Neundorf wrote: ...
The cmake files for building python are now in a cvs repository: http://www.cmake.org/cgi-bin/viewcvs.cgi/Utilities/CMakeBuildForPython/ ?roo t=ParaView3
Thanks for your work on this! That page seems to require a login. Any chance you could post it to something like::
http://wiki.python.org/moin/BuildingPythonWithCMake
I guess I need a login there too, so I put it somewhere where I already have one: http://www.cmake.org/Wiki/BuildingPythonWithCMake
Alex
participants (4)
-
Alexander Neundorf -
Facundo Batista -
Giovanni Bajo -
Steven Bethard