ParaView 5.8.1 Python CMake Flags

ParaView Support
1

Hi, the flags used to specify the Python interpreter to CMake don’t seem to be working for me at the moment - or maybe I’m missing something. I want to compile a PV install to use a specific Python interpreter and environment but the system Python keeps getting picked up instead.

Compiling v5.8.1 on CentOS 8, I used:

cmake -GNinja 
-DPARAVIEW_USE_PYTHON=ON 
-DPYTHON_EXECUTABLE=/home/tjim/anaconda3/envs/testenv/bin/python3.7 
-DPYTHON_LIBRARY=/home/tjim/anaconda3/envs/testenv/lib/libpython3.7m.so  
-DPYTHON_INCLUDE_DIR=/home/tjim/anaconda3/envs/testenv/include/python3.7m 
-DCMAKE_BUILD_TYPE=Release 
-DCMAKE_INSTALL_PREFIX=/opt/paraview/ParaView-5.8.1_testenv 
-DPARAVIEW_ENABLE_FFMPEG=ON -DPARAVIEW_USE_MPI=ON 
-DVTK_SMP_IMPLEMENTATION_TYPE=TBB 
-DVTK_MPI_NUMPROCS=10 
../paraview

but CMake defaults to the system python 3.6 and reports:

CMake Warning:
  Manually-specified variables were not used by the project:

    PYTHON_EXECUTABLE
    PYTHON_INCLUDE_DIR
    PYTHON_LIBRARY

I saw this, but if the flags don’t exist anymore, what did they become?
I also tried using a .cmake file instead and using find_program:

set(CMAKE_INSTALL_PREFIX "/opt/paraview/ParaView-5.8.1_testenv" CACHE PATH "")
SET(PARAVIEW_ENABLE_FFMPEG ON CACHE BOOL "")
SET(PARAVIEW_USE_PYTHON ON CACHE BOOL "")
SET(PARAVIEW_PYTHON_VERSION "3" CACHE STRING "")
SET(PARAVIEW_USE_MPI ON CACHE BOOL "")
SET(VTK_PYTHON_VERSION 3 CACHE STRING "")
SET(CMAKE_BUILD_TYPE "Release" CACHE STRING "")
SET(VTK_SMP_IMPLEMENTATION_TYPE "TBB" CACHE STRING "")
SET(VTK_MPI_NUMPROCS "10" CACHE STRING "")

find_program(PYTHON_EXECUTABLE "/home/tjim/anaconda3/envs/testenv/bin/python3.7")

but again, on running cmake -C../testenv.cmake -GNinja ../paraview, I get a message during the build:
-- Found Python3: /usr/lib64/libpython3.6m.so (found suitable version "3.6", minimum required is "3.2") found components: Development
Is this a bug? Thanks.

1 Like
2

I’ve found that the correct flags for Python from the cmake website are:

SET(Python3_EXECUTABLE "/home/tjim/anaconda3/envs/test/bin/python3.7" CACHE STRING "")
SET(Python3_LIBRARY "/home/tjim/anaconda3/envs/test/lib/libpython3.7m.so" CACHE STRING "")
SET(Python3_INCLUDE_DIR "/home/tjim/anaconda3/envs/test/include/python3.7m" CACHE STRING "")

However, it now picks up the Anaconda environment’s QT, even though the CMakeCache.txt appears to reference the QT under /usr/lib64/cmake/Qt5 - this is apparent when trying to run ./bin/paraview:

./bin/paraview: /home/tjim/anaconda3/envs/testenv/lib/libQt5Core.so.5: version `Qt_5.12' not found (required by ./bin/paraview)
./bin/paraview: /home/tjim/anaconda3/envs/testenv/lib/libQt5Core.so.5: version `Qt_5.12' not found (required by /opt/paraview/ParaView-5.8.1_testenv/bin/../lib64/libpqApplicationComponents-pv5.8.so.1)
./bin/paraview: /home/tjim/anaconda3/envs/testenv/lib/libQt5Core.so.5: version `Qt_5.12' not found (required by /opt/paraview/ParaView-5.8.1_testenv/bin/../lib64/libpqComponents-pv5.8.so.1)
./bin/paraview: /home/tjim/anaconda3/envs/testenv/lib/libQt5Core.so.5: version `Qt_5.12' not found (required by /opt/paraview/ParaView-5.8.1_testenv/bin/../lib64/libpqPython-pv5.8.so.1)
./bin/paraview: /home/tjim/anaconda3/envs/testenv/lib/libQt5Core.so.5: version `Qt_5.12' not found (required by /opt/paraview/ParaView-5.8.1_testenv/bin/../lib64/libpqCore-pv5.8.so.1)
./bin/paraview: /home/tjim/anaconda3/envs/testenv/lib/libQt5Core.so.5: version `Qt_5.12' not found (required by /opt/paraview/ParaView-5.8.1_testenv/bin/../lib64/libpqWidgets-pv5.8.so.1)
./bin/paraview: /home/tjim/anaconda3/envs/testenv/lib/libQt5Core.so.5: version `Qt_5.12' not found (required by /opt/paraview/ParaView-5.8.1_testenv/bin/../lib64/libvtkqttesting-pv5.8.so.1)
./bin/paraview: /home/tjim/anaconda3/envs/testenv/lib/libQt5Core.so.5: version `Qt_5.12' not found (required by /opt/paraview/ParaView-5.8.1_testenv/bin/../lib64/libvtkGUISupportQt-pv5.8.so.1)
./bin/paraview: /home/tjim/anaconda3/envs/testenv/lib/libQt5Core.so.5: version `Qt_5.12' not found (required by /lib64/libQt5Network.so.5)
./bin/paraview: /home/tjim/anaconda3/envs/testenv/lib/libQt5Core.so.5: version `Qt_5.12.5_PRIVATE_API' not found (required by /lib64/libQt5Network.so.5)

I tried setting the QT directories directly using extra flags (below) but I had the same issue.

SET(Qt5_DIR "/usr/lib64/cmake/Qt5" CACHE STRING "")
SET(Qt5Core_DIR "/usr/lib64/cmake/Qt5Core" CACHE STRING "")
SET(Qt5Gui_DIR "/usr/lib64/cmake/Qt5Gui" CACHE STRING "")
SET(Qt5Help_DIR "/usr/lib64/cmake/Qt5Help" CACHE STRING "")
SET(Qt5Network_DIR "/usr/lib64/cmake/Qt5Network" CACHE STRING "")
SET(Qt5Sql_DIR "/usr/lib64/cmake/Qt5Sql" CACHE STRING "")
SET(Qt5Svg_DIR "/usr/lib64/cmake/Qt5Svg" CACHE STRING "")
SET(Qt5Widgets_DIR "/usr/lib64/cmake/Qt5Widgets" CACHE STRING "")
SET(Qt5X11Extras_DIR "/usr/lib64/cmake/Qt5Widgets" CACHE STRING "")

Any ideas of how to set the QT paths independently of the Python paths? Perhaps someone who knows their way around cmake or Paraview’s usage of it? Thanks!

3

There is no way to do this if the Python and Qt libraries live next to each other. If you want just the Python ones and different Qt libraries, you’ll have to make a new environment without the Qt libraries.

4

Hi Ben, thanks for the update and clarification. I figured that this might have been the case. In the end, I uninstalled QT from my conda python environment just for the Paraview installation and then rolled back my conda environment afterwards, to stop PV linking to the python QT - a bit of a pain but it worked.

The order in which libraries are located is a bit of a mystery to me; it was half a year ago now, so Idon’t really remember, but I thought I could solve the issue by letting the PV just use the conda env’s QT but something didn’t work back then.

5

On Linux, search paths are generally shared between all library lookups. If you have:

  • A/libX.so
  • A/libY.so
  • B/libX.so
  • B/libY.so

the priority order for directories is shared when looking for both libX.so and libY.so, so there is no way to order these directories in such a way that A/libX.so and B/libY.so are selected at runtime.

1 Like