This subpackage contains an abstract base class representing a compiler and concrete implementations for common compilers. The compiler classes should not be instantiated directly, but created using the new_compiler() factory function. Compiler types provided by Packaging are listed in Standard compilers.
Factory function to generate an instance of some CCompiler subclass for the requested platform or compiler type.
If no argument is given for plat and compiler, the default compiler type for the platform (os.name) will be used: 'unix' for Unix and Mac OS X, 'msvc' for Windows.
If plat is given, it must be one of 'posix', 'darwin' or 'nt'. An invalid value will not raise an exception but use the default compiler type for the current platform.
If compiler is given, plat will be ignored, allowing you to get for example a 'unix' compiler object under Windows or an 'msvc' compiler under Unix. However, not all compiler types can be instantiated on every platform.
Do any platform-specific customization of a CCompiler instance. Mainly needed on Unix to plug in the information that varies across Unices and is stored in CPython’s Makefile.
Generate linker options for searching library directories and linking with specific libraries. libraries and library_dirs are, respectively, lists of library names (not filenames!) and search directories. Returns a list of command-line options suitable for use with some compiler (depending on the two format strings passed in).
Generate C preprocessor options (-D, -U, -I) as used by at least two types of compilers: the typical Unix compiler and Visual C++. macros is the usual thing, a list of 1- or 2-tuples, where (name,) means undefine (-U) macro name, and (name, value) means define (-D) macro name to value. include_dirs is just a list of directory names to be added to the header file search path (-I). Returns a list of command-line options suitable for either Unix compilers or Visual C++.
Determine the default compiler to use for the given platform.
osname should be one of the standard Python OS names (i.e. the ones returned by os.name) and platform the common value returned by sys.platform for the platform in question.
The default values are os.name and sys.platform.
Add or change a compiler
Print list of available compilers (used by the --help-compiler options to build, build_ext, build_clib).
Concrete subclasses of CCompiler are provided in submodules of the packaging.compiler package. You do not need to import them, using new_compiler() is the public API to use. This table documents the standard compilers; be aware that they can be replaced by other classes on your platform.
| name | description | notes |
|---|---|---|
| 'unix' | typical Unix-style command-line C compiler | [1] |
| 'msvc' | Microsoft compiler | [2] |
| 'bcpp' | Borland C++ compiler | |
| 'cygwin' | Cygwin compiler (Windows port of GCC) | |
| 'mingw32' | Mingw32 port of GCC (same as Cygwin in no-Cygwin mode) |
| [1] | The Unix compiler class assumes this behavior:
|
| [2] | On Windows, extension modules typically need to be compiled with the same compiler that was used to compile CPython (for example Microsoft Visual Studio .NET 2003 for CPython 2.4 and 2.5). The AMD64 and Itanium binaries are created using the Platform SDK. Under the hood, there are actually two different subclasses of CCompiler defined: one is compatible with MSVC 2005 and 2008, the other works with older versions. This should not be a concern for regular use of the functions in this module. Packaging will normally choose the right compiler, linker etc. on its own. To override this choice, the environment variables DISTUTILS_USE_SDK and MSSdk must be both set. MSSdk indicates that the current environment has been setup by the SDK’s SetEnv.Cmd script, or that the environment variables had been registered when the SDK was installed; DISTUTILS_USE_SDK indicates that the user has made an explicit choice to override the compiler selection done by Packaging. |
This module provides the abstract base class for the CCompiler classes. A CCompiler instance can be used for all the compile and link steps needed to build a single project. Methods are provided to set options for the compiler — macro definitions, include directories, link path, libraries and the like.
The abstract base class CCompiler defines the interface that must be implemented by real compiler classes. The class also has some utility methods used by several compiler classes.
The basic idea behind a compiler abstraction class is that each instance can be used for all the compile/link steps in building a single project. Thus, attributes common to all of those compile and link steps — include directories, macros to define, libraries to link against, etc. — are attributes of the compiler instance. To allow for variability in how individual files are treated, most of those attributes may be varied on a per-compilation or per-link basis.
The constructor for each subclass creates an instance of the Compiler object. Flags are dry_run (don’t actually execute the steps) and force (rebuild everything, regardless of dependencies). All of these flags default to False (off). Note that you probably don’t want to instantiate CCompiler or one of its subclasses directly - use the new_compiler() factory function instead.
The following methods allow you to manually alter compiler options for the instance of the Compiler class.
Add dir to the list of directories that will be searched for header files. The compiler is instructed to search directories in the order in which they are supplied by successive calls to add_include_dir().
Set the list of directories that will be searched to dirs (a list of strings). Overrides any preceding calls to add_include_dir(); subsequent calls to add_include_dir() add to the list passed to set_include_dirs(). This does not affect any list of standard include directories that the compiler may search by default.
Add libname to the list of libraries that will be included in all links driven by this compiler object. Note that libname should not be the name of a file containing a library, but the name of the library itself: the actual filename will be inferred by the linker, the compiler, or the compiler class (depending on the platform).
The linker will be instructed to link against libraries in the order they were supplied to add_library() and/or set_libraries(). It is perfectly valid to duplicate library names; the linker will be instructed to link against libraries as many times as they are mentioned.
Set the list of libraries to be included in all links driven by this compiler object to libnames (a list of strings). This does not affect any standard system libraries that the linker may include by default.
Add dir to the list of directories that will be searched for libraries specified to add_library() and set_libraries(). The linker will be instructed to search for libraries in the order they are supplied to add_library_dir() and/or set_library_dirs().
Set the list of library search directories to dirs (a list of strings). This does not affect any standard library search path that the linker may search by default.
Add dir to the list of directories that will be searched for shared libraries at runtime.
Set the list of directories to search for shared libraries at runtime to dirs (a list of strings). This does not affect any standard search path that the runtime linker may search by default.
Define a preprocessor macro for all compilations driven by this compiler object. The optional parameter value should be a string; if it is not supplied, then the macro will be defined without an explicit value and the exact outcome depends on the compiler used (XXX true? does ANSI say anything about this?)
Undefine a preprocessor macro for all compilations driven by this compiler object. If the same macro is defined by define_macro() and undefined by undefine_macro() the last call takes precedence (including multiple redefinitions or undefinitions). If the macro is redefined/undefined on a per-compilation basis (i.e. in the call to compile()), then that takes precedence.
Add object to the list of object files (or analogues, such as explicitly named library files or the output of “resource compilers”) to be included in every link driven by this compiler object.
Set the list of object files (or analogues) to be included in every link to objects. This does not affect any standard object files that the linker may include by default (such as system libraries).
The following methods implement methods for autodetection of compiler options, providing some functionality similar to GNU autoconf.
Detect the language of a given file, or list of files. Uses the instance attributes language_map (a dictionary), and language_order (a list) to do the job.
Search the specified list of directories for a static or shared library file lib and return the full path to that file. If debug is true, look for a debugging version (if that makes sense on the current platform). Return None if lib wasn’t found in any of the specified directories.
Return a boolean indicating whether funcname is supported on the current platform. The optional arguments can be used to augment the compilation environment by providing additional include files and paths and libraries and paths.
Return the compiler option to add dir to the list of directories searched for libraries.
Return the compiler option to add dir to the list of libraries linked into the shared library or executable.
Return the compiler option to add dir to the list of directories searched for runtime libraries.
Define the executables (and options for them) that will be run to perform the various stages of compilation. The exact set of executables that may be specified here depends on the compiler class (via the ‘executables’ class attribute), but most will have:
| attribute | description |
|---|---|
| compiler | the C/C++ compiler |
| linker_so | linker used to create shared objects and libraries |
| linker_exe | linker used to create binary executables |
| archiver | static library creator |
On platforms with a command line (Unix, DOS/Windows), each of these is a string that will be split into executable name and (optional) list of arguments. (Splitting the string is done similarly to how Unix shells operate: words are delimited by spaces, but quotes and backslashes can override this. See packaging.util.split_quoted().)
The following methods invoke stages in the build process.
Compile one or more source files. Generates object files (e.g. transforms a .c file to a .o file.)
sources must be a list of filenames, most likely C/C++ files, but in reality anything that can be handled by a particular compiler and compiler class (e.g. an 'msvc' compiler can handle resource files in sources). Return a list of object filenames, one per source filename in sources. Depending on the implementation, not all source files will necessarily be compiled, but all corresponding object filenames will be returned.
If output_dir is given, object files will be put under it, while retaining their original path component. That is, foo/bar.c normally compiles to foo/bar.o (for a Unix implementation); if output_dir is build, then it would compile to build/foo/bar.o.
macros, if given, must be a list of macro definitions. A macro definition is either a (name, value) 2-tuple or a (name,) 1-tuple. The former defines a macro; if the value is None, the macro is defined without an explicit value. The 1-tuple case undefines a macro. Later definitions/redefinitions/undefinitions take precedence.
include_dirs, if given, must be a list of strings, the directories to add to the default include file search path for this compilation only.
debug is a boolean; if true, the compiler will be instructed to output debug symbols in (or alongside) the object file(s).
extra_preargs and extra_postargs are implementation-dependent. On platforms that have the notion of a command line (e.g. Unix, DOS/Windows), they are most likely lists of strings: extra command-line arguments to prepend/append to the compiler command line. On other platforms, consult the implementation class documentation. In any event, they are intended as an escape hatch for those occasions when the abstract compiler framework doesn’t cut the mustard.
depends, if given, is a list of filenames that all targets depend on. If a source file is older than any file in depends, then the source file will be recompiled. This supports dependency tracking, but only at a coarse granularity.
Raises CompileError on failure.
Link a bunch of stuff together to create a static library file. The “bunch of stuff” consists of the list of object files supplied as objects, the extra object files supplied to add_link_object() and/or set_link_objects(), the libraries supplied to add_library() and/or set_libraries(), and the libraries supplied as libraries (if any).
output_libname should be a library name, not a filename; the filename will be inferred from the library name. output_dir is the directory where the library file will be put. XXX defaults to what?
debug is a boolean; if true, debugging information will be included in the library (note that on most platforms, it is the compile step where this matters: the debug flag is included here just for consistency).
target_lang is the target language for which the given objects are being compiled. This allows specific linkage time treatment of certain languages.
Raises LibError on failure.
Link a bunch of stuff together to create an executable or shared library file.
The “bunch of stuff” consists of the list of object files supplied as objects. output_filename should be a filename. If output_dir is supplied, output_filename is relative to it (i.e. output_filename can provide directory components if needed).
libraries is a list of libraries to link against. These are library names, not filenames, since they’re translated into filenames in a platform-specific way (e.g. foo becomes libfoo.a on Unix and foo.lib on DOS/Windows). However, they can include a directory component, which means the linker will look in that specific directory rather than searching all the normal locations.
library_dirs, if supplied, should be a list of directories to search for libraries that were specified as bare library names (i.e. no directory component). These are on top of the system default and those supplied to add_library_dir() and/or set_library_dirs(). runtime_library_dirs is a list of directories that will be embedded into the shared library and used to search for other shared libraries that *it* depends on at run-time. (This may only be relevant on Unix.)
export_symbols is a list of symbols that the shared library will export. (This appears to be relevant only on Windows.)
debug is as for compile() and create_static_lib(), with the slight distinction that it actually matters on most platforms (as opposed to create_static_lib(), which includes a debug flag mostly for form’s sake).
extra_preargs and extra_postargs are as for compile() (except of course that they supply command-line arguments for the particular linker being used).
target_lang is the target language for which the given objects are being compiled. This allows specific linkage time treatment of certain languages.
Raises LinkError on failure.
Link an executable. output_progname is the name of the file executable, while objects are a list of object filenames to link in. Other arguments are as for the link() method.
Link a shared library. output_libname is the name of the output library, while objects is a list of object filenames to link in. Other arguments are as for the link() method.
Link a shared object. output_filename is the name of the shared object that will be created, while objects is a list of object filenames to link in. Other arguments are as for the link() method.
Preprocess a single C/C++ source file, named in source. Output will be written to file named output_file, or stdout if output_file not supplied. macros is a list of macro definitions as for compile(), which will augment the macros set with define_macro() and undefine_macro(). include_dirs is a list of directory names that will be added to the default list, in the same way as add_include_dir().
Raises PreprocessError on failure.
The following utility methods are defined by the CCompiler class, for use by the various concrete subclasses.
Returns the filename of the executable for the given basename. Typically for non-Windows platforms this is the same as the basename, while Windows will get a .exe added.
Returns the filename for the given library name on the current platform. On Unix a library with lib_type of 'static' will typically be of the form liblibname.a, while a lib_type of 'dynamic' will be of the form liblibname.so.
Returns the name of the object files for the given source files. source_filenames should be a list of filenames.
Returns the name of a shared object file for the given file name basename.
Invokes packaging.util.execute() This method invokes a Python function func with the given arguments args, after logging and taking into account the dry_run flag. XXX see also.
Invokes packaging.util.spawn(). This invokes an external process to run the given command. XXX see also.
Invokes packaging.dir_util.mkpath(). This creates a directory and any missing ancestor directories. XXX see also.
Invokes packaging.file_util.move_file(). Renames src to dst. XXX see also.
This module provides the Extension class, used to represent C/C++ extension modules.
The Extension class describes a single C or C++ extension module. It accepts the following keyword arguments in its constructor:
| argument name | value | type |
|---|---|---|
| name | the full name of the extension, including any packages — i.e. not a filename or pathname, but Python dotted name | string |
| sources | 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. | list of strings |
| include_dirs | list of directories to search for C/C++ header files (in Unix form for portability) | list of strings |
| define_macros | list of macros to define; each macro is defined using a 2-tuple (name, value), where value is either the string to define it to or None to define it without a particular value (equivalent of #define FOO in source or -DFOO on Unix C compiler command line) | list of tuples |
| undef_macros | list of macros to undefine explicitly | list of strings |
| library_dirs | list of directories to search for C/C++ libraries at link time | list of strings |
| libraries | list of library names (not filenames or paths) to link against | list of strings |
| runtime_library_dirs | list of directories to search for C/C++ libraries at run time (for shared extensions, this is when the extension is loaded) | list of strings |
| extra_objects | list of extra files to link with (e.g. object files not implied by ‘sources’, static library that must be explicitly specified, binary resource files, etc.) | list of strings |
| extra_compile_args | any extra platform- and compiler-specific information to use when compiling the source files in ‘sources’. For platforms and compilers where a command line makes sense, this is typically a list of command-line arguments, but for other platforms it could be anything. | list of strings |
| extra_link_args | 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’. | list of strings |
| export_symbols | 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. | list of strings |
| depends | list of files that the extension depends on | list of strings |
| language | extension language (i.e. 'c', 'c++', 'objc'). Will be detected from the source extensions if not provided. | string |
| optional | specifies that a build failure in the extension should not abort the build process, but simply skip the extension. | boolean |
To distribute extension modules that live in a package (e.g. package.ext), you need to create a package/__init__.py file to let Python recognize and import your module.
