Then copy these files over to the Python source directory, so that the
toplevel CMakeLists.txt ends up in the toplevel Python directory.
Building svn Python or Python >
With Python from svn (not Python 3000) or Python 2.6.0 (not released
yet, September 2007), the patch mentioned above for handling unicode and
disabled dynamic loading isn't necessary anymore. Here's how you can get
Python from Python svn and the CMake files for Python, which are in
$ svn co http://svn.python.org/projects/python/trunk python-with-cmake$ cvs -d :pserver:firstname.lastname@example.org:/cvsroot/ParaView3 login<empty password>$ cvs -d :pserver:email@example.com:/cvsroot/ParaView3 co -d python-with-cmake ParaView3/Utilities/CMakeBuildForPython
The commands shown above will check out Python and the CMake files in
the same directory, which will be both a CVS and a svn working directory
at the same time. While this is a bit unusual it works, since svn and
CVS use different meta data directories (.svn/ vs. CVS/).
Building Python 2.7.1 to 2.7.3
The build system of "David Sansome" looks very promising.
It allows a lot of flexibility in the way python can be built and
embedded in existing application.
Just run CMake on it as usual, then make, make install. Under Windows
this is tested with VisualStudio 2003. Under Windows the tests in
ConfigureChecks.cmake are not actually executed, but the pyconfig.h for
Windows which is part of the Python sources is used as is. This is
actually not necessary, the tests could be executed the same way as they
are executed under Windows, but to get this working probably some flags,
include files etc. have to be adjusted, and I didn't have the time to do
this yet. As a difference to the original Python build for Windows not
all modules are built into a huge python.dll, but instead they are built
as separate plugins (as under Linux).
Building Python for other operating systems
Building Python using CMake for other operating systems like OS X, *BSD
etc. shouldn't require a lot of work, maybe it already works out of the
box. Probably some configure checks have to be tweaked.
Cross compiling Python for BlueGene/L
Cross compiling Python for BlueGene is easy, since in
python-with-cmake/CMake/ there is a file
TryRunResults-Python-bgl-gcc.cmake, which contains the results for the
TRY_RUN() tests which are executed by CMake when configuring Python.
Since we are cross compiling CMake can't actually run these tests, but
the results have to be supplied manually. This is done in this case by
preloading the CMake cache using the mentioned file:
~/src/python-with-cmake/ $~/src/python-with-cmake/ $ mkdir build-bgl~/src/python-with-cmake/~$ cd build-bgl~/src/python-with-cmake/build-bgl/ $ cmake -DCMAKE_TOOLCHAIN_FILE=~/Toolchain-BlueGeneL-gcc.cmake -DCMAKE_INSTALL_PREFIX=~/bgl-install -C ../CMake/TryRunResults-Python-bgl-gcc.cmake .....~/src/python-with-cmake/build-bgl/ $ make...~/src/python-with-cmake/build-bgl/ $ make install...
Cross compiling Python for Cray Xt3/ Catamount
Cross compiling Python for Cray Xt3/Catamount is easy, since in
python-with-cmake/CMake/ there is a file
TryRunResults-Python-catamount-gcc.cmake, which contains the results for
the TRY_RUN() tests which are executed by CMake when configuring
Python. Since we are cross compiling CMake can't actually run these
tests, but the results have to be supplied manually. This is done in
this case by preloading the CMake cache using the mentioned file:
The python module pwd has to be disabled by setting
MODULE_pwd_ENABLE to OFF, since the getpw*() functions are not
available under Catamount.
~/src/python-with-cmake/build-catamount/ $ make...~/src/python-with-cmake/build-catamount/ $ make install...
When linking it all together there are a lot of warnings about posix_*
functions, where the linker warns that they will fail at runtime. They
come from the posix module. But this has to be built, it's presence
itself is used by python to detect that it's running on a POSIX-like
This will finish with two errors, one for each TRY_RUN(), since this is
cross compiling and CMake doesn't try to execute the executables. CMake
will have created a file TryRunResults.cmake, This will finish with two
-- Performing Test HAVE_BROKEN_NICECMake Error: TRY_RUN() invoked in cross-compiling mode, please set the following cache variables appropriatly: HAVE_BROKEN_NICE_EXITCODE (advanced)For details see ~/src/python-with-cmake/build-ecos/TryRunResults.cmake-- Performing Test HAVE_BROKEN_NICE - Failed-- Performing Test HAVE_BROKEN_POLLCMake Error: TRY_RUN() invoked in cross-compiling mode, please set the following cache variables appropriatly: HAVE_BROKEN_POLL_EXITCODE (advanced)For details see ~/src/python-with-cmake/build-ecos/TryRunResults.cmake-- Performing Test HAVE_BROKEN_POLL - Failed
These are two system tests, where cmake used TRY_RUN() to test an
executable, but since they are cross compiled, it didn't try to run them
but instead produced these error messages. As the messages say have a
look at ~/src/python-with-cmake/build-ecos/TryRunResults.cmake . You
will find the executables which were not run in the build directory,
named cmTryCompileExec-HAVE_BROKEN_NICE_EXITCODE and
cmTryCompileExec-HAVE_BROKEN_POLL_EXITCODE. You can try to run them
on the target to see what there exit code is and put these results into
the TryRunResults.cmake file. After that you should copy this file to a
safe place, otherwise it gets overwritten on the next CMake run and your
changes are lost. Then use this file to preload the CMake cache with the
results from the
Builds on Linux, Windows and cross compiles to eCos, IBM BlueGene/L
and Cray Xt3/Catamount
the python library can be built as shared or static library, RPATH
each module can be enabled and disabled separatly
on systems without shared libs everything is build static, modules
are linked into the python library
packages can be created using cpack (or "make package"): rpm, deb,
tgz, stgz, zip, nsis and more
Enable the configure checks on Windows, so the premade pyconfig.h
file can go away.
Trying to build it on other platforms like *BSD, Apple. This
shouldn't be much work.
Adding the remaining modules to the build. Should be just work, no
major problems expected.
Add rules to bytecompile (or how it is called) the python modules to
The python executable is currently installed with the version number
in their name.
Module not found
If the Python executable and the python library have been built and
installed successfully and you can execute simple things, it still can
happen that some modules are not found. Currently not all Python modules
are built and not everything is installed. In this case have a look at
python-with-svn/CMakeLists.txt and search in the list of
ADD_PYTHON_MODULE() commands if your module is included. Some modules
are disabled by default, you can enable building them by setting the
option BUILD_UNTESTED_MODULES to TRUE. Other modules are still
completely missing. If this is the case, figure out what the source
files for this module are and add it to this list. If it is built and
installed, but Python still doesn't find it, it's time for debugging. A
good start might be python-with-svn/Python/import.c .
This page was initially populated by conversion from its original location in another wiki.