cmake находит неправильных библиотек Python - PullRequest
17 голосов
/ 05 октября 2011

Я новичок в CMake и у меня проблемы с пониманием некоторых концепций использования.

Я вызываю скрипт на python из программы на c ++:

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

Соответствующие записи cmake в моемФайл cmake:

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

Это работает, если мой скрипт на python не использует какие-либо модули, установленные в каталоге site-packages, в противном случае я получаю ошибку ImportError. Этот вопрос показывает, как найти местоположение каталога site-packages с CMake, но что мне сказать CMake с ним делать?

РЕДАКТИРОВАТЬ: Проблема решена.Оказывается, FIND_PACKAGE (PythonLibs) находит инсталляцию Python, отличную от той, которую я обычно использую (/usr/local/lib/libpython2.7.dylib вместо /Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.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.

Ответы [ 4 ]

14 голосов
/ 07 октября 2013

Лучший способ решить проблему с обнаружением неправильной версии (например, 3.0 вместо 2.7) - указать минимальную версию для find_package (при этом будет выбрана любая версия> = 2.7):

FIND_PACKAGE(PythonLibs 2.7 REQUIRED)

или получить точную версию:

FIND_PACKAGE(PythonLibs 2.7.5 EXACT REQUIRED)
13 голосов
/ 21 марта 2012

Вы можете указать cmake, где найти эти PythonLibs, указав путь к вашим библиотекам python следующим образом:

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

Это тогда установит $ {PYTHON_LIBRARIES} внутри cmake на правильный путь.

Чтобы узнать, какие другие возможные опции (кроме 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 голос
/ 15 марта 2016

Вы можете настроить вручную на cmake libs \usr\share\cmake-3.2.3\Modules\FindPythonLibs.cmake:

set(PYTHON_LIBRARY "\\usr\\lib\\python2.7")
set(PYTHON_INCLUDE_DIR "\\usr\\include\\python2.7")
0 голосов
/ 05 октября 2011

Вы фактически встраиваете python в свою программу, когда делаете это.Вы вызывали Py_Initialize () до PyRun_SimpleFile?Взгляните на Встраивание Python в другое приложение .

Py_Initialize () установит sys.path и необходим для установки среды Python.

Если вы можете найтитам, где установлен python, можно установить python home для переопределения вычислений пути python.Используйте Py_SetPythonHome () перед Py_Initialize ().

В операционных системах типа 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.
 */
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...