安装python模块(旧版)¶
- 作者
格雷格·沃德
注解
整个 distutils
软件包已弃用,将在Python 3.12中删除。本文档仅作为参考保留,并将随软件包一起删除。请参阅 What's New 有关更多信息,请登录。
参见
- 安装python模块
最新的模块安装文档。对于常规的python用法,您几乎肯定想要那个文档而不是这个文档。
注解
本文件仅保留至 setuptools
https://setuptools.readthedocs.io/en/latest/setuptools.html上的文档独立地涵盖了此处当前包含的所有相关信息。
注解
本指南仅涵盖构建和分发扩展的基本工具,这些扩展是作为此版本的Python的一部分提供的。第三方工具提供了更易于使用和更安全的替代方案。参考 quick recommendations section _有关详细信息,请参阅《Python打包用户指南》。
介绍¶
在python 2.0中, distutils
API首先被添加到标准库中。这为Linux发行版维护人员提供了将python项目转换为Linux发行版包的标准方法,并为系统管理员提供了将它们直接安装到目标系统上的标准方法。
自python 2.0发布以来的许多年里,将构建系统和包安装程序紧密耦合到语言运行时发布周期已被证明是有问题的,现在建议项目使用 pip
软件包安装程序和 setuptools
构建系统,而不是使用 distutils
直接。
见 安装python模块 和 分发python模块 了解更多详细信息。
只有在我们确信 setuptools
文档涵盖了所有需要的内容。
基于distuils的源分布¶
如果您下载了一个模块源代码分发版,您可以很快地知道它是否是以标准方式打包和分发的,即使用distutils。首先,分发的名称和版本号将突出显示在下载的存档文件的名称中,例如 foo-1.0.tar.gz
或 widget-0.9.7.zip
. 接下来,归档文件将解包到一个同名目录中: foo-1.0
或 widget-0.9.7
.此外,分发将包含一个安装脚本 setup.py
和一个名为 README.txt
或者可能只是 README
,这应该解释构建和安装模块分发是从终端运行一个命令的简单问题:
python setup.py install
对于Windows,应该从命令提示窗口运行此命令 (
):setup.py install
如果所有这些都是正确的,那么您已经知道如何构建和安装刚刚下载的模块:运行上面的命令。除非您需要以非标准方式安装东西或定制构建过程,否则您并不真正需要本手册。或者更确切地说,上面的命令就是您需要从本手册中得到的一切。
标准建造和安装¶
如第节所述 基于distuils的源分布 ,使用distutils构建和安装模块分发通常是从终端运行的一个简单命令:
python setup.py install
平台变化¶
您应该始终从分发根目录(即模块源分发解包到的顶级子目录)运行安装命令。例如,如果您刚下载了一个模块源分发版 foo-1.0.tar.gz
在UNIX系统上,通常要做的事情是:
gunzip -c foo-1.0.tar.gz | tar xf - # unpacks into directory foo-1.0
cd foo-1.0
python setup.py install
在Windows上,您可能会下载 foo-1.0.zip
. 如果您将存档文件下载到 C:\Temp
然后它会打开 C:\Temp\foo-1.0
;可以将存档操纵器与图形用户界面(如winzip)或命令行工具(如 unzip 或 pkunzip )打开归档文件。然后,打开命令提示窗口并运行:
cd c:\Temp\foo-1.0
python setup.py install
拆分任务¶
运行 setup.py install
在一次运行中生成和安装所有模块。如果您更类似于增量工作——如果您想要定制构建过程,或者事情出了问题,那么特别有用——您可以使用安装脚本一次完成一件事情。当构建和安装将由不同的用户完成时,这尤其有用——例如,您可能希望构建一个模块分发版,并将其交给系统管理员进行安装(或者使用超级用户权限自己进行安装)。
例如,通过两次调用安装脚本,您可以在一个步骤中构建所有内容,然后在第二个步骤中安装所有内容:
python setup.py build
python setup.py install
如果您这样做,您会注意到运行 install 命令首先运行 build 命令,在这种情况下,它很快注意到它没有任何作用,因为 build
目录是最新的。
如果您所做的只是安装从网络上下载的模块,那么您可能不需要这种能力来经常分解问题,但是对于更高级的任务来说,它非常方便。如果您开始分发自己的python模块和扩展,您将单独运行许多distuils命令。
如何开展工作¶
正如上面所暗示的那样, build 命令负责将要安装的文件放入 建立目录 . 默认情况下,这是 build
在分布根目录下;如果您过分关注速度,或者希望保持源码树的原始性,可以使用 --build-base
选项。例如::
python setup.py build --build-base=/path/to/pybuild/foo-1.0
(或者您可以使用系统或个人distutils配置文件中的指令永久执行此操作;请参见第节 distutils配置文件 一般来说,这是不必要的。
生成树的默认布局如下:
--- build/ --- lib/
or
--- build/ --- lib.<plat>/
temp.<plat>/
在哪里? <plat>
扩展到当前操作系统/硬件平台和Python版本的简要描述。第一张表格,只有一张 lib
目录,用于“纯模块分发”--即仅包含纯Python模块的模块分发。如果模块分布包含任何扩展(用C/C++编写的模块),那么第二种形式有两个 <plat>
使用目录。在这种情况下, temp.{plat}
目录保存编译/链接进程生成的临时文件,这些文件实际上没有安装。在这两种情况下, lib
(或) lib.{plat}
)目录包含将要安装的所有python模块(纯python和扩展)。
将来,将添加更多目录来处理python脚本、文档、二进制可执行文件,以及处理安装python模块和应用程序所需的其他内容。
安装工作原理¶
后 build 命令运行(无论您是显式运行它,还是 install 命令为你做的),的工作 install 命令相对简单:它所要做的就是复制 build/lib
(或) build/lib.{plat}
)到您选择的安装目录。
如果您不选择安装目录,也就是说,如果您只是运行 setup.py install
---然后 install 命令安装到第三方python模块的标准位置。这个位置因平台和构建/安装python本身的方式而异。在Unix(以及基于Unix的Mac OS X)上,它还取决于所安装的模块分发是纯Python还是包含扩展(“非纯”):
Platform |
标准安装位置 |
默认值 |
笔记 |
---|---|---|---|
UNIX(纯) |
|
|
(1) |
UNIX(非纯) |
|
|
(1) |
Windows |
|
|
(2) |
笔记:
大多数Linux发行版都将python作为系统的标准部分,因此
{prefix}
和{exec-prefix}
通常都是/usr
在Linux上。如果您自己在Linux(或任何类似于Unix的系统)上构建python,则默认{prefix}
和{exec-prefix}
是/usr/local
.Windows上的默认安装目录是
C:\Program Files\Python
在python 1.6a1、1.5.2和更早版本下。
{prefix}
和 {exec-prefix}
代表安装了python的目录,以及在运行时找到其库的位置。它们在Windows下总是相同的,在Unix和Mac OS X下也常常相同。您可以了解python安装的用途。 {prefix}
和 {exec-prefix}
通过在交互模式下运行python并键入一些简单的命令。在Unix下,只需键入 python
在shell提示下。在Windows下,选择 . 一旦解释器启动,您就可以在提示下键入python代码。例如,在我的Linux系统上,我键入下面所示的三个python语句,并获得如图所示的输出,以找出 {prefix}
和 {exec-prefix}
:
Python 2.4 (#26, Aug 7 2004, 17:19:02)
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.prefix
'/usr'
>>> sys.exec_prefix
'/usr'
此文档中使用了其他几个占位符: {X.Y}
例如,代表python的版本 3.2
; {abiflags}
将替换为 sys.abiflags
或者没有定义ABI标志的平台的空字符串; {distname}
将替换为正在安装的模块分发的名称。点和大写在路径中很重要;例如,使用 python3.2
在Unix上通常使用 Python32
在Windows上。
如果您不想将模块安装到标准位置,或者您没有在此位置写入的权限,那么您需要阅读第节中有关备用安装的内容。 备用安装 . 如果您想更严格地自定义安装目录,请参见 自定义安装 在自定义安装时。
备用安装¶
通常,将模块安装到第三方Python模块的标准位置以外的位置是必要的或可取的。例如,在UNIX系统上,您可能没有写入标准第三方模块目录的权限。或者,您可能希望在将某个模块作为本地Python安装的标准部分之前对其进行尝试。当升级已经存在的分发版时尤其如此:在实际升级之前,您需要确保现有的脚本库仍然与新版本一起工作。
ditudil install 命令旨在使将模块分发安装到另一个位置变得简单和轻松。基本思想是为安装提供一个基本目录,并且 install 命令选择一组目录(称为 安装方案 )在这个基本目录下安装文件。不同平台的详细信息不同,请阅读以下适用于您的部分。
请注意,各种备选安装方案相互排斥:您可以通过 --user
或 --home
或 --prefix
和 --exec-prefix
或 --install-base
和 --install-platbase
但是你不能从这些组中混合。
备用安装:用户方案¶
此方案旨在为对全局站点包目录没有写权限或不希望安装到其中的用户提供最方便的解决方案。它是通过一个简单的选项启用的:
python setup.py install --user
文件将安装到的子目录中 site.USER_BASE
(写成) {userbase}
此后)。此方案在同一位置安装纯Python模块和扩展模块(也称为 site.USER_SITE
)以下是Unix的值,包括Mac OS X:
文件类型 |
安装目录 |
---|---|
模块 |
|
脚本 |
|
数据 |
|
C标题 |
|
以下是Windows上使用的值:
文件类型 |
安装目录 |
---|---|
模块 |
|
脚本 |
|
数据 |
|
C标题 |
|
与下面描述的其他方案相比,使用此方案的优势在于,用户站点包目录在正常情况下始终包含在 sys.path
(见 site
有关详细信息),这意味着在运行 setup.py
用于完成安装的脚本。
这个 build_ext 命令还具有 --user
添加选项 {userbase}/include
到头文件的编译器搜索路径 {userbase}/lib
到库的编译器搜索路径以及共享C库的运行时搜索路径(rpath)。
替代安装:家庭方案¶
“主方案”背后的想法是您构建并维护一个个人的Python模块存储库。这个方案的名称源于Unix上的“home”目录的概念,因为对于Unix用户来说,使其home目录的布局类似于 /usr/
或 /usr/local/
. 任何人都可以使用此方案,无论他们安装的操作系统是什么。
安装新的模块分发版非常简单:
python setup.py install --home=<dir>
您可以在其中为 --home
选择权。在UNIX上,懒惰的打字员只需键入一个颚化符 (~
; install 命令将此目录扩展到主目录:
python setup.py install --home=~
要让python找到与此方案一起安装的发行版,您可能必须 modify Python's search path 或编辑 sitecustomize
(见 site
调用 site.addsitedir()
或编辑 sys.path
.
这个 --home
选项定义安装基目录。文件安装到安装库下的以下目录中,如下所示:
文件类型 |
安装目录 |
---|---|
模块 |
|
脚本 |
|
数据 |
|
C标题 |
|
(如果你在 Windows 上,用反斜杠代替斜杠。)
备用安装:unix(前缀方案)¶
如果您希望使用一个python安装来执行构建/安装(即运行安装脚本),但将模块安装到另一个python安装的第三方模块目录中(或类似于另一个python安装的目录),则“前缀方案”非常有用。如果这听起来有点不寻常,那就是——这就是为什么用户和家庭计划出现在前面的原因。但是,至少有两种已知的情况下前缀方案是有用的。
首先,考虑许多Linux发行版将python /usr
而不是更传统的 /usr/local
. 这是完全合适的,因为在这些情况下,Python是“系统”的一部分,而不是本地附加组件。但是,如果您要从源代码安装python模块,您可能希望它们进入 /usr/local/lib/python2.{X}
而不是 /usr/lib/python2.{X}
. 这可以通过以下方式完成:
/usr/bin/python setup.py install --prefix=/usr/local
另一种可能是网络文件系统,其中用于写入远程目录的名称与用于读取该目录的名称不同:例如,python解释器访问时 /usr/local/bin/python
可能在中搜索模块 /usr/local/lib/python2.{X}
但是这些模块必须安装到,比如, /mnt/{@server}/export/lib/python2.{X}
. 这可以通过以下方式完成:
/usr/local/bin/python setup.py install --prefix=/mnt/@server/export
在这两种情况下, --prefix
选项定义安装基础,以及 --exec-prefix
选项定义平台特定的安装库,用于平台特定的文件。(目前,这仅仅意味着非纯模块分发,但可以扩展到C库、二进制可执行文件等)如果 --exec-prefix
未提供,默认为 --prefix
. 文件安装如下:
文件类型 |
安装目录 |
---|---|
python模块 |
|
扩展模块 |
|
脚本 |
|
数据 |
|
C标题 |
|
没有要求 --prefix
或 --exec-prefix
实际上指向另一个python安装;如果上面列出的目录不存在,则在安装时创建它们。
顺便说一句,前缀方案之所以重要,是因为标准的UNIX安装使用前缀方案,但是 --prefix
和 --exec-prefix
由python本身提供 sys.prefix
和 sys.exec_prefix
. 因此,您可能认为永远不会使用前缀方案,但每次运行时 python setup.py install
如果没有其他选择,你就可以使用它。
注意,将扩展安装到另一个python安装中不会影响这些扩展的构建方式:特别是python头文件 (Python.h
与用于运行安装脚本的python解释器一起安装的,将用于编译扩展。您有责任确保用于运行以这种方式安装的扩展的解释器与用于构建扩展的解释器兼容。做到这一点的最佳方法是确保两个解释程序是同一版本的Python(可能是不同的版本,也可能是同一版本的副本)。(当然,如果您的 --prefix
和 --exec-prefix
甚至不要指向另一个python安装,这是无关紧要的。)
备用安装:Windows(前缀方案)¶
Windows没有用户主目录的概念,而且由于Windows下的标准python安装比Unix下的简单,因此 --prefix
选项通常用于在Windows的不同位置安装其他软件包。::
python setup.py install --prefix="\Temp\Python"
将模块安装到 \Temp\Python
当前驱动器上的目录。
安装基础由 --prefix
选择权; --exec-prefix
Windows不支持选项,这意味着纯Python模块和扩展模块安装在同一位置。文件安装如下:
文件类型 |
安装目录 |
---|---|
模块 |
|
脚本 |
|
数据 |
|
C标题 |
|
自定义安装¶
有时,第节中描述的替代安装方案 备用安装 只是不要做你想做的。您可能只需要调整一个或两个目录,同时将所有内容保持在同一个基目录下,或者您可能需要完全重新定义安装方案。无论哪种情况,您都在创建 自定义安装方案 .
要创建自定义安装方案,请从一个备用方案开始,并使用以下选项覆盖用于各种类型文件的某些安装目录:
文件类型 |
超越选项 |
---|---|
python模块 |
|
扩展模块 |
|
所有模块 |
|
脚本 |
|
数据 |
|
C标题 |
|
这些覆盖选项可以是相对的、绝对的,也可以是根据一个安装基目录显式定义的。(有两个安装基目录,它们通常是相同的---它们只有在使用unix“前缀方案”并提供不同的 --prefix
和 --exec-prefix
选择;使用 --install-lib
将重写为计算或给定的值 --install-purelib
和 --install-platlib
,对于不区分python和扩展模块的方案,建议使用。)
例如,假设您正在Unix下安装一个模块分发到您的主目录——但是您希望脚本进入 ~/scripts
而不是 ~/bin
. 如您所料,您可以使用 --install-scripts
选项;在这种情况下,最有意义的做法是提供一个相对路径,该路径将相对于安装基目录(在本例中是您的主目录)进行解释:
python setup.py install --home=~ --install-scripts=scripts
另一个UNIX示例:假设您的python安装是以前缀 /usr/local/python
,因此在标准安装脚本中 /usr/local/python/bin
. 如果你想让他们进来 /usr/local/bin
相反,您将为 --install-scripts
选项:
python setup.py install --install-scripts=/usr/local/bin
(这将使用“prefix scheme”执行安装,其中prefix是安装了Python解释器的--- /usr/local/python
在这种情况下)
如果在Windows上维护python,您可能希望第三方模块位于 {prefix}
而不是直接进入 {prefix}
本身。这几乎和定制脚本安装目录一样简单——您只需记住,有两种类型的模块需要担心:python和extension模块,这两种模块都可以方便地由一个选项控制:
python setup.py install --install-lib=Site
指定的安装目录相对于 {prefix}
.当然,还必须确保该目录位于Python的模块搜索路径中,例如 .pth
站点目录中的文件(请参见 site
)见节 修改python的搜索路径 了解如何修改python的搜索路径。
如果要定义整个安装方案,只需提供所有安装目录选项。建议的方法是提供相对路径;例如,如果要在下面维护所有与python模块相关的文件 python
在主目录中,如果要为使用主目录的每个平台分别定义一个目录,可以定义以下安装方案:
python setup.py install --home=~ \
--install-purelib=python/lib \
--install-platlib=python/lib.$PLAT \
--install-scripts=python/scripts
--install-data=python/data
或者,等价地:
python setup.py install --home=~/python \
--install-purelib=lib \
--install-platlib='lib.$PLAT' \
--install-scripts=scripts
--install-data=data
$PLAT
不是(必须)一个环境变量---它将在解析命令行选项时由distuils扩展,就像解析配置文件时那样。
显然,每次安装新的模块分发版时都要指定整个安装方案是非常繁琐的。因此,可以将这些选项放入distutils配置文件(请参见第节 distutils配置文件 ):
[install]
install-base=$HOME
install-purelib=python/lib
install-platlib=python/lib.$PLAT
install-scripts=python/scripts
install-data=python/data
或者,等价地,
[install]
install-base=$HOME/python
install-purelib=lib
install-platlib=lib.$PLAT
install-scripts=scripts
install-data=data
注意这两个是 not 如果在运行安装脚本时提供不同的安装基目录,则等效。例如:
python setup.py install --install-base=/tmp
将纯模块安装到 /tmp/python/lib
在第一种情况下, /tmp/lib
在第二种情况下。(对于第二种情况,您可能希望提供 /tmp/python
)
你可能注意到了 $HOME
和 $PLAT
在示例配置文件输入中。这些是distuils配置变量,与环境变量非常相似。实际上,您可以在具有这样一个概念的平台上的配置文件中使用环境变量,但是distuils还定义了一些可能不在您的环境中的额外变量,例如 $PLAT
. (当然,在没有环境变量的系统上,例如Mac OS 9,distutils提供的配置变量是唯一可以使用的配置变量。)请参见第节 distutils配置文件 有关详细信息。
注解
当A virtual environment 如果激活,则所有distuils配置文件中更改安装路径的任何选项都将被忽略,以防止无意中在虚拟环境之外安装项目。
修改python的搜索路径¶
当python解释器执行 import
语句,它沿着搜索路径搜索python代码和扩展模块。在构建解释器时,路径的默认值被配置为python二进制文件。您可以通过导入 sys
模块和打印值 sys.path
. ::
$ python
Python 2.2 (#11, Oct 3 2002, 13:31:27)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/local/lib/python2.3', '/usr/local/lib/python2.3/plat-linux2',
'/usr/local/lib/python2.3/lib-tk', '/usr/local/lib/python2.3/lib-dynload',
'/usr/local/lib/python2.3/site-packages']
>>>
中的空字符串 sys.path
表示当前工作目录。
本地安装包的预期约定是将它们放入 {...}/site-packages/
目录,但您可能希望将python模块安装到某个任意目录中。例如,您的站点可能有一个惯例,将与Web服务器相关的所有软件保存在 /www
. 然后,附加的python模块可能属于 /www/python
,并且为了导入它们,必须将此目录添加到 sys.path
. 添加目录有几种不同的方法。
最方便的方法是将路径配置文件添加到已经在python路径上的目录中,通常添加到 .../site-packages/
目录。路径配置文件的扩展名为 .pth
,并且每行必须包含一个将附加到 sys.path
. (因为新路径附加到 sys.path
,添加的目录中的模块不会覆盖标准模块。这意味着您不能使用此机制安装标准模块的固定版本。)
路径可以是绝对路径或相对路径,在这种情况下,它们是相对于包含 .pth
文件。参见 site
模块了解更多信息。
稍微不方便的方法是编辑 site.py
在python的标准库中,并修改 sys.path
. site.py
在执行python解释器时自动导入,除非 -S
开关用于抑制这种行为。所以你可以简单地编辑 site.py
并添加两行:
import sys
sys.path.append('/www/python/')
但是,如果您重新安装了同一个主要版本的python(例如,当从2.2升级到2.2.2时)。 site.py
将被库存版本覆盖。在安装之前,您必须记住它已被修改并保存了一个副本。
有两个环境变量可以修改 sys.path
. PYTHONHOME
为python安装的前缀设置备用值。例如,如果 PYTHONHOME
设置为 /www/python
,搜索路径将设置为 ['', '/www/python/lib/pythonX.Y/', '/www/python/lib/pythonX.Y/plat-linux2', ...]
.
这个 PYTHONPATH
变量可以设置为将添加到 sys.path
. 例如,如果 PYTHONPATH
设置为 /www/python:/opt/py
,搜索路径将以开始 ['/www/python', '/opt/py']
. (请注意,目录必须存在才能添加到 sys.path
; site
模块删除不存在的路径。)
最后, sys.path
只是一个普通的python列表,所以任何python应用程序都可以通过添加或删除条目来修改它。
distutils配置文件¶
如上所述,您可以使用distuils配置文件记录任何distuils选项的个人或站点首选项。也就是说,任何命令的任何选项都可以存储在两个或三个(取决于您的平台)配置文件中的一个文件中,在解析命令行之前,将参考这些文件。这意味着配置文件将覆盖默认值,而命令行将反过来覆盖配置文件。此外,如果应用多个配置文件,“早期”文件中的值将被“后期”文件覆盖。
配置文件的位置和名称¶
配置文件的名称和位置在不同的平台上略有不同。在UNIX和Mac OS X上,三个配置文件(按处理顺序)是:
文件类型 |
位置和文件名 |
笔记 |
---|---|---|
系统 |
|
(1) |
个人的 |
|
(2) |
地方的 |
|
(3) |
在Windows上,配置文件是:
文件类型 |
位置和文件名 |
笔记 |
---|---|---|
系统 |
|
(4) |
个人的 |
|
(5) |
地方的 |
|
(3) |
在所有平台上,通过传递 --no-user-cfg 选择权。
笔记:
严格来说,系统范围的配置文件位于安装distutils的目录中;在python 1.6及更高版本的unix下,如图所示。对于python 1.5.2,distuils通常安装在
{prefix}/lib/python1.5/site-packages/distutils
,所以系统配置文件应该放在python 1.5.2下。在UNIX上,如果
HOME
未定义环境变量,将使用getpwuid()
标准中的功能pwd
模块。这是由os.path.expanduser()
distutils使用的函数。即,在当前目录中(通常是安装脚本的位置)。
(另请参见注释(1)。)在python 1.6和更高版本下,python的默认“安装前缀”是
C:\Python
,因此系统配置文件通常C:\Python\Lib\distutils\distutils.cfg
.在python 1.5.2中,默认前缀是C:\Program Files\Python
和distuils不是标准库的一部分,因此系统配置文件C:\Program Files\Python\distutils\distutils.cfg
在Windows下的标准python 1.5.2安装中。在Windows上,如果
HOME
未定义环境变量,USERPROFILE
然后HOMEDRIVE
和HOMEPATH
将尝试。这是由os.path.expanduser()
distutils使用的函数。
配置文件的语法¶
distutils配置文件都具有相同的语法。配置文件分为多个部分。每个distutils命令有一个部分,加上 global
影响每个命令的全局选项的部分。每段每行包含一个选项,指定为 option=value
.
例如,以下是一个完整的配置文件,默认情况下只强制所有命令安静运行:
[global]
verbose=0
如果将其安装为系统配置文件,它将影响当前系统上任何用户对任何python模块分发的所有处理。如果它安装为您的个人配置文件(在支持它们的系统上),它将只影响您处理的模块分发。如果它被用作 setup.cfg
对于特定的模块分发,它只影响该分发。
您可以重写默认的“build base”目录,并使 build* 命令始终使用以下命令强制重新生成所有文件:
[build]
build-base=blib
force=1
对应于命令行参数:
python setup.py build --build-base=blib --force
除此之外,包括 build 命令行上的命令意味着将运行该命令。在配置文件中包含一个特定的命令并没有这样的含义;它只意味着如果运行该命令,配置文件中的选项将应用。(或者,如果运行从中派生值的其他命令,则它们将使用配置文件中的值。)
您可以使用 --help
选项,例如:
python setup.py build --help
您可以使用 --help
没有命令:
python setup.py --help
另请参见“分布式Python模块”手册的“参考”部分。
构建扩展:提示和技巧¶
只要可能,distuils就会尝试使用运行 setup.py
脚本。例如,用于编译python的编译器和链接器标志也将用于编译扩展。通常这会很好地工作,但在复杂的情况下,这可能是不适当的。本节讨论如何重写通常的distuils行为。
调整编译器/链接器标志¶
编译用C或C++编写的Python扩展有时需要为编译器和链接器指定自定义标志,以便使用特定的库或产生一种特殊类型的对象代码。如果扩展没有在您的平台上进行测试,或者您正试图交叉编译Python,那么这一点尤其正确。
在最一般的情况下,扩展作者可能已经预见到编译扩展会很复杂,并且提供了一个 Setup
文件供您编辑。只有当模块分发包含多个独立的扩展模块时,或者它们通常需要精心设置的编译器标志集才能工作时,才可能完成此操作。
A Setup
文件(如果存在)将被解析,以便获得要生成的扩展名列表。A中的每一行 Setup
描述单个模块。行具有以下结构:
module ... [sourcefile ...] [cpparg ...] [library ...]
让我们依次检查每个字段。
模块 是要生成的扩展模块的名称,并且应该是有效的Python标识符。您不能仅仅为了重命名一个模块而更改它(也需要对源代码进行编辑),所以应该将其单独保存。
源文件 是任何可能是源代码文件的文件,至少根据文件名判断。文件名结尾为
.c
假定以c开头,文件名以.C
,.cc
和.c++
假设为C++,文件名终止于.m
或.mm
假设在目标C中。CPPARG 是C预处理器的参数,并且是以
-I
,-D
,-U
或-C
.类库 有什么结尾吗
.a
或者从-l
或-L
.
如果特定平台需要平台上的特殊库,可以通过编辑 Setup
文件和运行 python setup.py build
. 例如,如果由行定义的模块:
foo foomodule.c
必须与数学库链接 libm.a
在您的平台上,只需添加 -lm
到:
foo foomodule.c -lm
用于编译器或链接器的任意开关可以随 -Xcompiler
arg 和 -Xlinker
arg 选项:
foo foomodule.c -Xcompiler -o32 -Xlinker -shared -lm
之后的下一个选项 -Xcompiler
和 -Xlinker
将附加到适当的命令行,因此在上面的示例中,编译器将通过 -o32
选项,链接器将被传递 -shared
. 如果编译器选项需要参数,则必须提供多个 -Xcompiler
选项;例如,传递 -x c++
这个 Setup
文件必须包含 -Xcompiler -x -Xcompiler c++
.
也可以通过设置 CFLAGS
环境变量。如果设置,则 CFLAGS
将添加到 Setup
文件。
在Windows上使用非Microsoft编译器¶
Borland/CordEng+ C+¶
本节描述了使用Borland C++编译器版本5.5的ditudil的必要步骤。首先,您必须知道Borland的对象文件格式(OMF)与您可以从python或activestate网站下载的python版本所使用的格式不同。(Python是用微软Visual C++构建的,它使用COFF作为对象文件格式。)为此,您必须转换Python的库。 python25.lib
变成Borland格式。您可以这样做:
coff2omf python25.lib python25_bcpp.lib
这个 coff2omf
程序附带了Borland编译器。文件 python25.lib
是在 Libs
python安装的目录。如果您的扩展使用其他库(zlib,…),那么您也必须转换它们。
转换后的文件必须与普通库位于同一目录中。
distuils如何使用这些更改了名称的库?如果扩展需要库(例如 foo
)distutils首先检查是否找到带有后缀的库 _bcpp
(例如) foo_bcpp.lib
)然后使用这个库。如果它找不到这样一个特殊的库,它将使用默认名称 (foo.lib
) 1
要让ditudil用Borland C++编译扩展,现在必须键入:
python setup.py build --compiler=bcpp
如果您想使用Borland C++编译器作为默认值,可以在个人或全系统配置文件中指定diditul(参见 distutils配置文件 )
参见
- C++Builder Compiler
关于Borland的免费C++编译器的信息,包括下载页面的链接。
- Creating Python Extensions Using Borland's Free Compiler
描述如何使用Borland的自由命令行C++编译器来构建Python的文档。
GNU C/Cygwin/Mingw公司¶
本节描述了在Gyc/C++编译器中使用dituTIL的必要步骤。 2 对于使用cygwin构建的python解释器,没有以下任何步骤,一切都可以工作。
不是所有的扩展都可以用mingw或cygwin构建,但是很多扩展可以。最可能不工作的扩展是使用C++或依赖于微软Visual C扩展的那些扩展。
要让distuils使用cygwin编译扩展,必须键入:
python setup.py build --compiler=cygwin
对于非cygwin模式下的cygwin 3 或Mingw型:
python setup.py build --compiler=mingw32
如果要将这些选项/编译器中的任何一个作为默认值,则应考虑将其写入distuils的个人或系统范围的配置文件(请参见第节 distutils配置文件 )
python和mingw的旧版本¶
以下说明仅适用于使用低于2.4.1、mingw低于3.0.0(使用binutils-2.13.90-20030111-1)的python版本的情况。
这些编译器需要一些特殊的库。这个任务比Borland的C++更复杂,因为没有程序来转换库。首先,您必须创建一个由python dll导出的符号列表。(您可以在https://sourceforge.net/projects/mingw/files/mingw/extension/pexports/上找到适合此任务的程序)。
pexports python25.dll >python25.def
安装的位置 python25.dll
将取决于安装选项以及Windows的版本和语言。在“只为我”安装中,它将显示在安装目录的根目录中。在共享安装中,它将位于系统目录中。
然后,您可以根据这些信息为gcc创建一个导入库。::
/cygwin/bin/dlltool --dllname python25.dll --def python25.def --output-lib libpython25.a
生成的库必须与 python25.lib
. (应该是 libs
python安装目录下的目录。)
如果您的扩展使用其他库(zlib,…),您可能也需要转换它们。转换后的文件必须与普通库位于同一目录中。
参见
- Building Python modules on MS Windows platform with MinGW
有关为Mingw环境构建所需库的信息。
脚注