cmake trouve mal libs python

Question

Je suis nouveau à CMake et j'ai du mal à comprendre certains concepts d'utilisation.

J'appelle un script python à partir d'un programme C++:

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

Les entrées de CMake correspondantes dans mon fichier cmake sont:

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

Cela fonctionne aussi longtemps que mon script python ISN » t en utilisant n'importe quel module installé dans le répertoire site-packages, sinon j'obtiens un ImportError. This question montre comment trouver l'emplacement du répertoire site-packages avec CMake, mais que dois-je dire à CMake?

EDIT: Problème résolu. Il s'avère que FIND_PACKAGE (PythonLibs) trouve une installation python différente de celle que j'utilise normalement (/usr/local/lib/libpython2.7.dylib au lieu de /Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2. 7.dylib - je suis sur mac), c'est comme ça que j'obtiens des modules python standard, mais aucun que je n'ai installé moi-même. Pour remettre le PYTHONPATH à la normale, j'ai ajouté

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

en haut de mon script python.

Answer 1

Vous pouvez dire CMake où trouver ce PythonLibs en spécifiant le chemin d'accès à vos bibliothèques Python comme ceci:

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

ce sera alors mis le $ {} PYTHON_LIBRARIES l'intérieur cMake sur le droit chemin.

Pour connaître les autres options possibles (en plus PYTHON_LIBRARIES) vous pouvez donner à CMake (avec l'option -DARG) essayez d'exécuter

ccmake . 

Appuyez ensuite sur c pour configurer et t pour les options avancées.

Par exemple, vous pouvez également définir

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

Answer 2

Vous intégrez effectivement Python dans votre programme lorsque vous faites cela. Avez-vous appelé Py_Initialize() avant PyRun_SimpleFile? Jetez un oeil à Embedding Python in Another Application.

Py_Initialize() va configurer sys.path et est requis pour définir l'environnement python.

Si vous pouvez trouver où python est installé, il est possible de définir python home pour remplacer les calculs de chemin python. Utilisez Py_SetPythonHome() avant Py_Initialize().

sur les systèmes d'exploitation de type POSIX, voici un commentaire dans getpath.c (mise en œuvre de CPython de chemin de résolution):

/* 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. 
*/ 

Answer 3

La meilleure façon de résoudre le problème que la mauvaise version se trouve (par exemple 3,0 au lieu de 2,7) est de spécifier la version minimale à find_package (ceci choisira n'importe quelle version> = 2.7):

FIND_PACKAGE(PythonLibs 2.7 REQUIRED) 

ou pour obtenir la version exacte:

FIND_PACKAGE(PythonLibs 2.7.5 EXACT REQUIRED) 

Answer 4

Vous pouvez configurer manuellement sur libs 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")