You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the answer, a PYTHON_VERSION option should be used to explicitly specify the python interpreter, but an incorrect behavior is observed on a system where the python3 interpreter is the default one (e.g. Arch). Despite the PYTHON_VERSION=2 is being set, the result of find_package(PythonInterp) (called here) is not /usr/bin/python2, but /usr/bin/python.
Versions: python3 3.6.3 is the default one /usr/bin/python python2 2.7.14 also present, but as /usr/bin/python2 only cmake 3.8
Example output:
> catkin_make --cmake-args -DPYTHON_VERSION=2
Base path: /home/testuser/dev/rosproj
Source space: /home/testuser/dev/rosproj/src
Build space: /home/testuser/dev/rosproj/build
Devel space: /home/testuser/dev/rosproj/devel
Install space: /home/testuser/dev/rosproj/install
######## Running command: "cmake /home/testuser/dev/rosproj/src -DPYTHON_VERSION=2 -DCATKIN_DEVEL_PREFIX=/home/testuser/dev/rosproj/devel -DCMAKE_INSTALL_PREFIX=/home/testuser/dev/rosproj/install -G Unix Makefiles" in "/home/testuser/dev/rosproj/build"####
-- The C compiler identification is GNU 7.2.0
-- The CXX compiler identification is GNU 7.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using CATKIN_DEVEL_PREFIX: /home/testuser/dev/rosproj/devel
-- Using CMAKE_PREFIX_PATH: /opt/ros/kinetic
-- This workspace overlays: /opt/ros/kinetic
-- Found PythonInterp: /usr/bin/python (found suitable version "3.6.3", minimum required is "2")
-- Using PYTHON_EXECUTABLE: /usr/bin/python
-- Using default Python package layout
-- Could NOT find PY_em (missing: PY_EM)
CMake Error at /opt/ros/kinetic/share/catkin/cmake/empy.cmake:29 (message):
Unable to find either executable 'empy' or Python module 'em'... try
installing the package 'python-empy'
Call Stack (most recent call first):
/opt/ros/kinetic/share/catkin/cmake/all.cmake:147 (include)
/opt/ros/kinetic/share/catkin/cmake/catkinConfig.cmake:20 (include)
CMakeLists.txt:52 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/testuser/dev/rosproj/build/CMakeFiles/CMakeOutput.log".
Invoking "cmake" failed
I've looked at the usage of PYTHON_VERSION option and it seems that setting just the PythonInterp_FIND_VERSION is not enough for find_package command to do its job properly. From the CMake sources it's clear that the FindPython module also relies on the PythonInterp_FIND_VERSION_COUNT, PythonInterp_FIND_VERSION_MAJOR, etc. options. Probably these variables are propagated only if the find_package is called with the version in the arguments, e.g. find_package(PythonInterp "${PYTHON_VERSION}" REQUIRED), which actually resolves the issue.
The text was updated successfully, but these errors were encountered:
According to the answer, a
PYTHON_VERSION
option should be used to explicitly specify the python interpreter, but an incorrect behavior is observed on a system where the python3 interpreter is the default one (e.g. Arch). Despite thePYTHON_VERSION=2
is being set, the result offind_package(PythonInterp)
(called here) is not/usr/bin/python2
, but/usr/bin/python
.Versions:
python3 3.6.3
is the default one/usr/bin/python
python2 2.7.14
also present, but as/usr/bin/python2
onlycmake 3.8
Example output:
I've looked at the usage of
PYTHON_VERSION
option and it seems that setting just thePythonInterp_FIND_VERSION
is not enough forfind_package
command to do its job properly. From the CMake sources it's clear that the FindPython module also relies on thePythonInterp_FIND_VERSION_COUNT
,PythonInterp_FIND_VERSION_MAJOR
, etc. options. Probably these variables are propagated only if thefind_package
is called with the version in the arguments, e.g.find_package(PythonInterp "${PYTHON_VERSION}" REQUIRED)
, which actually resolves the issue.The text was updated successfully, but these errors were encountered: