[Python-Dev] Evaluated cmake as an autoconf replacement

[Alexander Neundorf]

On Tue, Apr 7, 2009 at 3:23 PM, David Cournapeau <cournape at gmail.com> wrote:
> On Tue, Apr 7, 2009 at 10:08 PM, Alexander Neundorf
> <alex.neundorf at kitware.com> wrote:
>
>>
>> What is involved in building python extensions ? Can you please explain ?
>
> Not much: at the core, a python extension is nothing more than a
> dynamically loaded library + a couple of options.

CMake has support (slightly but intentionally undocumented) for this,
from FindPythonLibs.cmake:

# PYTHON_ADD_MODULE(<name> src1 src2 ... srcN) is used to build
modules for python.
# PYTHON_WRITE_MODULES_HEADER(<filename>) writes a header file you can include
# in your sources to initialize the static python modules

Using python_add_module(name file1.c file2.c) you can build python
modules, and decide at cmake time whether it should be a dynamically
loaded module (default) or whether it should be built as a static
library (useful for platforms without shared libs).
Installation then happens simply via
install(TARGETS ...)

> One choice is whether to take options from distutils or to set them up

What options ?

> independently. In my own scons tool to build python extensions, both
> are possible.
>
> The hard (or rather time consuming) work is to do everything else that
> distutils does related to the packaging. That's where scons/waf are
> more interesting than cmake IMO, because you can "easily" give up this
> task back to distutils, whereas it is inherently more difficult with
> cmake.

Can you please explain ?
It is easy to run external tools with cmake at cmake time and at build
time, and it is also possible to run them at install time.

Alex