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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4