2011-10-05 75 views
15

我是CMake的新手,无法理解一些使用概念。cmake发现错误的python库

我打电话从C Python脚本++程序:在我的cmake文件

#include <Python.h> 
... 
Py_Initialize(); 
PyRun_SimpleFile(...); 
Py_Finalize(); 

相应cmake的项目有:

FIND_PACKAGE(PythonLibs REQUIRED) 
... 
TARGET_LINK_LIBRARIES(MyApplication ${PYTHON_LIBRARIES}) 

这只要可以作为我的python脚本ISN” t使用安装在site-packages目录中的任何模块,否则我得到一个ImportError。 This question显示了如何使用CMake找到site-packages目录的位置,但我应该告诉CMake如何处理它?

编辑:问题解决了。原来,FIND_PACKAGE(PythonLibs)从我通常使用的(/usr/local/lib/libpython2.7.dylib而不是/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2)中找到了不同的python安装。 7.dylib - 我在Mac上),这是我如何获得标准的Python模块,但没有我自己安装。要将PYTHONPATH改回正常状态,我添加了

try: 
    import some_package 
except ImportError: 
    if "my_python_path" in sys.path: raise 
    sys.path.append("my_python_path") 

位于我的python脚本的顶部。

+0

在什么平台上,你运行?因为搜索路径根据平台而被非常不同地解决。 – David

+0

你不应该为你的问题添加一个答案。相反,您可以在解决方案中添加以下实际答案 – Joakim

回答

12

你可以告诉cmake的地方通过指定要喜欢你的Python库的路径找到这个PythonLibs这个:

cmake -DPYTHON_LIBRARIES=/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib . 

然后这会将cmake中的$ {PYTHON_LIBRARIES}设置为正确的路径。

要找出其他可能的选项(除了PYTHON_LIBRARIES)可以给你的cmake(与-DARG选项)尝试运行

ccmake . 

然后按c配置,并为t高级选项。

例如,你可能还需要设置

-DPYTHON_LIBRARY='/softwarepath/Python/Python2.7/lib/libpython2.7.so' 
-DPYTHON_INCLUDE='/softwarepath/Python/Python2.7/include' 
+1

有趣的是,include目录在我的情况下找到正确,但链接到错误的Python版本! – dashesy

+3

我认为现在CMake标志(用2.8.12.1测试)-DPYTHON_INCLUDE_DIR = $ PYTHON_ROOT/include/pythonX.Y和-DPYTHON_LIBRARY = $ PYTHON_ROOT/lib/libpythonX.Y.so(来自FindPythonLibs.cmake模块描述) – Ax3l

0

当你这样做时,你可以有效地在程序中嵌入python。您是否在PyRun_SimpleFile之前调用Py_Initialize()?看看Embedding Python in Another Application

Py_Initialize()将设置sys.path并且需要设置python环境。

如果您可以找出python的安装位置,可以将python home设置为覆盖python路径计算。在Py_Initialize()之前使用Py_SetPythonHome()。

在POSIX类型操作系统,这里是getpath.c评论(路径的CPython的执行解析):

/* Search in some common locations for the associated Python libraries. 
* 
* Two directories must be found, the platform independent directory 
* (prefix), containing the common .py and .pyc files, and the platform 
* dependent directory (exec_prefix), containing the shared library 
* modules. Note that prefix and exec_prefix can be the same directory, 
* but for some installations, they are different. 
* 
* Py_GetPath() carries out separate searches for prefix and exec_prefix. 
* Each search tries a number of different locations until a ``landmark'' 
* file or directory is found. If no prefix or exec_prefix is found, a 
* warning message is issued and the preprocessor defined PREFIX and 
* EXEC_PREFIX are used (even though they will not work); python carries on 
* as best as is possible, but most imports will fail. 
* 
* Before any searches are done, the location of the executable is 
* determined. If argv[0] has one or more slashes in it, it is used 
* unchanged. Otherwise, it must have been invoked from the shell's path, 
* so we search $PATH for the named executable and use that. If the 
* executable was not found on $PATH (or there was no $PATH environment 
* variable), the original argv[0] string is used. 
* 
* Next, the executable location is examined to see if it is a symbolic 
* link. If so, the link is chased (correctly interpreting a relative 
* pathname if one is found) and the directory of the link target is used. 
* 
* Finally, argv0_path is set to the directory containing the executable 
* (i.e. the last component is stripped). 
* 
* With argv0_path in hand, we perform a number of steps. The same steps 
* are performed for prefix and for exec_prefix, but with a different 
* landmark. 
* 
* Step 1. Are we running python out of the build directory? This is 
* checked by looking for a different kind of landmark relative to 
* argv0_path. For prefix, the landmark's path is derived from the VPATH 
* preprocessor variable (taking into account that its value is almost, but 
* not quite, what we need). For exec_prefix, the landmark is 
* Modules/Setup. If the landmark is found, we're done. 
* 
* For the remaining steps, the prefix landmark will always be 
* lib/python$VERSION/os.py and the exec_prefix will always be 
* lib/python$VERSION/lib-dynload, where $VERSION is Python's version 
* number as supplied by the Makefile. Note that this means that no more 
* build directory checking is performed; if the first step did not find 
* the landmarks, the assumption is that python is running from an 
* installed setup. 
* 
* Step 2. See if the $PYTHONHOME environment variable points to the 
* installed location of the Python libraries. If $PYTHONHOME is set, then 
* it points to prefix and exec_prefix. $PYTHONHOME can be a single 
* directory, which is used for both, or the prefix and exec_prefix 
* directories separated by a colon. 
* 
* Step 3. Try to find prefix and exec_prefix relative to argv0_path, 
* backtracking up the path until it is exhausted. This is the most common 
* step to succeed. Note that if prefix and exec_prefix are different, 
* exec_prefix is more likely to be found; however if exec_prefix is a 
* subdirectory of prefix, both will be found. 
* 
* Step 4. Search the directories pointed to by the preprocessor variables 
* PREFIX and EXEC_PREFIX. These are supplied by the Makefile but can be 
* passed in as options to the configure script. 
* 
* That's it! 
* 
* Well, almost. Once we have determined prefix and exec_prefix, the 
* preprocessor variable PYTHONPATH is used to construct a path. Each 
* relative path on PYTHONPATH is prefixed with prefix. Then the directory 
* containing the shared library modules is appended. The environment 
* variable $PYTHONPATH is inserted in front of it all. Finally, the 
* prefix and exec_prefix globals are tweaked so they reflect the values 
* expected by other code, by stripping the "lib/python$VERSION/..." stuff 
* off. If either points to the build directory, the globals are reset to 
* the corresponding preprocessor variables (so sys.prefix will reflect the 
* installation location, even though sys.path points into the build 
* directory). This seems to make more sense given that currently the only 
* known use of sys.prefix and sys.exec_prefix is for the ILU installation 
* process to find the installed Python tree. 
*/ 
+0

抱歉,我在描述中太简短。 Py_Initialize()和Py_Finalize()在那里:正如我所说,我调用的python脚本运行良好 - 只要它不依赖于站点包模块。 – margold

12

,最好的办法来解决问题是错误的版本被发现(例如3.0而不是2.7)是指定的最低版本find_package(这将选择任何版本> = 2。7):

FIND_PACKAGE(PythonLibs 2.7 REQUIRED) 

或得到确切的版本:

FIND_PACKAGE(PythonLibs 2.7.5 EXACT REQUIRED) 
1

,您可以手动设置在cmake的库\usr\share\cmake-3.2.3\Modules\FindPythonLibs.cmake

set(PYTHON_LIBRARY "\\usr\\lib\\python2.7") 
set(PYTHON_INCLUDE_DIR "\\usr\\include\\python2.7")