building plugins/modules with paraview-5.7.0 cmake

ParaView Support
1

Despite some pointers from @Joachim_Pouderoux and references to the build.md, I’m still not getting very far with compiling additional addons with ParaView-5.7.0 or with using VTK libraries from the paraview installation.

I’ve listed the basic categories of issues that I’m encountered as scenarios and leave it the to KitWare people if we keep this as a single topic, split it up, or spin off into a FAQ.

Scenario 1:

Code using VTK, where I have previously successfully used ParaView VTK libraries:

elseif (EXISTS "$ENV{ParaView_DIR}")
    message("Building with Paraview from $ENV{ParaView_DIR}")
    find_package(ParaView REQUIRED HINTS $ENV{ParaView_DIR})
else()

This appears to continue working adequately, but whereas previously the ParaViewConfig.cmake would contain references to VTK_CONFIG_FILE and also define list(APPEND VTK_INCLUDE_DIRS ...), the mechanism for 5.7.0 has been changed and I can’t find docs describing how the update should look like. Specifically, the following bit fails since it cannot find the include/libs:

try_compile(MYPROG_USING_VTK_MPI
    ${CMAKE_CURRENT_BINARY_DIR} ${test_file}
    LINK_LIBRARIES vtkParallelMPI
    CMAKE_FLAGS "-DINCLUDE_DIRECTORIES=${VTK_INCLUDE_DIRS}"
)

The vtkMPICommunicator.h and libvtkParallelMPI-pv5.7.so are available in their respective include/paraview-5.7 and lib64 directories, but can’t see what is missing for them to be found.

Scenario 2:

Re-using ParaView libraries for Catalyst applications. I’ve been following how trimmed Catalyst editions will be reworked for 5.8, but I’m content enough to use the full-blown ParaView sources for now (convenient, and expedient). For the build I’ve added an explicit -DPARAVIEW_ENABLE_CATALYST=ON, -DVTK_MODULE_ENABLE_ParaView_Catalyst=YES and -DVTK_MODULE_ENABLE_ParaView_PythonCatalyst=YES flags during the build. The installation contains corresponding libvtkPVCatalyst-pv5.7.so.5.7, libvtkPVPythonCatalyst-pv5.7.so.5.7 files, but I can’t see which other files it should require.

The initial discovery fails

    find_package(ParaView REQUIRED COMPONENTS vtkPVPythonCatalyst)

So it appears that I need some different syntax here. The subsequent tests also fail:

try_compile(MYPROG_CATALYST_HAS_CWD
    ${CMAKE_CURRENT_BINARY_DIR} ${test_file}
    LINK_LIBRARIES vtkPVPythonCatalyst
    CMAKE_FLAGS "-DINCLUDE_DIRECTORIES=${PARAVIEW_INCLUDE_DIRS}"
)

Scenario 3:

Building ParaView plugins for an existing installation. With the help of @Joachim_Pouderoux, we have the plugins restructured to use paraview_plugin_scan and paraview_plugin_build, but this seems to produce some very odd behaviour.

  • The name of the plugin is used directly withour a lib prefix, which seem to prevent regular library loading.
  • The name of the plugin is created as an extra directory, which means that we then have installation into lib/paraview-5.7/myPlugin/myPlugin.so instead of simply lib/paraview-5.7/libmyPlugin.so.
  • The intermediate library (for a client/server plugin) is either installed as a static, or a dynamic library - cannot seem to fully suppress its generation.

I hope this provides sufficient information.

Cheers,
/mark

2

cc: @ben.boeckel

3

This is the wrong way to check for libraries now. You can just do if (TARGET VTK::ParallelMPI) in this case. Note that ParaView finds all of VTK, so you’re OK for now, but in general, a find_package(VTK OPTIONAL_COMPONENTS ParallelMPI) would be needed to actually make it usable.

The right spelling is PythonCatalyst. If that succeeds, the target exists and will be usable (spelled ParaView::PythonCatalyst).

Plugins are not meant to be linked to directly, so the lib doesn’t matter.

This is done so that any plugin-local modules live right next to the plugin and can easily be moved around as a single unit.

It will always be made; I can look at making its installation suppressed however.

I’ll be working on docs for plugins in 5.7 (and 5.8) via https://gitlab.kitware.com/paraview/paraview/issues/19470 if you want to keep an eye on it.

1 Like
4

Progressing a bit further…

Ok, changing to OPTIONAL_COMPONENTS certainly makes for less writing, but does mean some gymnastics for handling different versions. For example,

find_package(ParaView REQUIRED HINTS $ENV{ParaView_DIR})
if (${ParaView_VERSION} GREATER_EQUAL 5.7)
    find_package(ParaView REQUIRED HINTS $ENV{ParaView_DIR}
        REQUIRED COMPONENTS PythonCatalyst
        OPTIONAL_COMPONENTS VTK::ParallelMPI)
else()
    find_package(ParaView REQUIRED HINTS $ENV{ParaView_DIR}
        REQUIRED COMPONENTS vtkPVPythonCatalyst)
endif()

Not even sure if that would be correct. For VTK it’s a bit uglier still since we need to synthesize a VTK_VERSION for older versions.

[NOTE: earlier post re-edited, found local config error that was causing some build issues]

5

Tagged the earlier response from Ben as the “solution”.
My builds are still a bit clunky, but they are building, which is something really really nice.
Thank you very much @ben.boeckel!

Cheers,
/mark