3.10. setup

3.10.1. Module Contents

3.10.1.1. Classes

CMakeExtension	Describes a single extension module.
CMakeBuild	Abstract base class for defining command classes, the "worker bees"

3.10.1.2. Functions

warning(s)
get_cmake_dir()
get_base_dir()

3.10.1.3. Attributes

version
package_data

setup.warning(s)

setup.get_cmake_dir()

setup.get_base_dir()

setup.version

class setup.CMakeExtension(name, sourcedir='')

Bases: setuptools.Extension

Describes a single extension module.

This means that all source files will be compiled into a single binary file <module path>.<suffix> (with <module path> derived from name and <suffix> defined by one of the values in importlib.machinery.EXTENSION_SUFFIXES).

In the case .pyx files are passed as sources and Cython is not installed in the build environment, setuptools may also try to look for the equivalent .cpp or .c files.

Parameters:

• name (str) – the full name of the extension, including any packages – ie. not a filename or pathname, but Python dotted name

• sources (list[str]) – list of source filenames, relative to the distribution root (where the setup script lives), in Unix form (slash-separated) for portability. Source files may be C, C++, SWIG (.i), platform-specific resource files, or whatever else is recognized by the “build_ext” command as source for a Python extension.

• include_dirs (list[str]) – list of directories to search for C/C++ header files (in Unix form for portability)

• define_macros (list[tuple[str, str|None]]) – list of macros to define; each macro is defined using a 2-tuple: the first item corresponding to the name of the macro and the second item either a string with its value or None to define it without a particular value (equivalent of “#define FOO” in source or -DFOO on Unix C compiler command line)

• undef_macros (list[str]) – list of macros to undefine explicitly

• library_dirs (list[str]) – list of directories to search for C/C++ libraries at link time

• libraries (list[str]) – list of library names (not filenames or paths) to link against

• runtime_library_dirs (list[str]) – list of directories to search for C/C++ libraries at run time (for shared extensions, this is when the extension is loaded). Setting this will cause an exception during build on Windows platforms.

• extra_objects (list[str]) – list of extra files to link with (eg. object files not implied by ‘sources’, static library that must be explicitly specified, binary resource files, etc.)

• extra_compile_args (list[str]) – any extra platform- and compiler-specific information to use when compiling the source files in ‘sources’. For platforms and compilers where “command line” makes sense, this is typically a list of command-line arguments, but for other platforms it could be anything.

• extra_link_args (list[str]) – any extra platform- and compiler-specific information to use when linking object files together to create the extension (or to create a new static Python interpreter). Similar interpretation as for ‘extra_compile_args’.

• export_symbols (list[str]) – list of symbols to be exported from a shared extension. Not used on all platforms, and not generally necessary for Python extensions, which typically export exactly one symbol: “init” + extension_name.

• swig_opts (list[str]) – any extra options to pass to SWIG if a source file has the .i extension.

• depends (list[str]) – list of files that the extension depends on

• language (str) – extension language (i.e. “c”, “c++”, “objc”). Will be detected from the source extensions if not provided.

• optional (bool) – specifies that a build failure in the extension should not abort the build process, but simply not install the failing extension.

• py_limited_api (bool) – opt-in flag for the usage of Python’s limited API.

Raises:

setuptools.errors.PlatformError – if ‘runtime_library_dirs’ is specified on Windows. (since v63)

class setup.CMakeBuild(dist)

Bases: setuptools.command.build_ext.build_ext

Abstract base class for defining command classes, the “worker bees” of the Distutils. A useful analogy for command classes is to think of them as subroutines with local variables called “options”. The options are “declared” in ‘initialize_options()’ and “defined” (given their final values, aka “finalized”) in ‘finalize_options()’, both of which must be defined by every command class. The distinction between the two is necessary because option values might come from the outside world (command line, config file, …), and any options dependent on other options must be computed after these outside influences have been processed – hence ‘finalize_options()’. The “body” of the subroutine, where it does all its work based on the values of its options, is the ‘run()’ method, which must also be implemented by every command class.

run()

Build extensions in build directory, then copy if –inplace

build_extension(ext)

setup.package_data