# building plugins/modules with paraview-5.7.0 cmake
**URL:** https://discourse.paraview.org/t/building-plugins-modules-with-paraview-5-7-0-cmake/3323
**Category:** ParaView Support
**Tags:** vtk
**Created:** [January 13, 2020, 11:51am UTC](https://discourse.paraview.org/t/building-plugins-modules-with-paraview-5-7-0-cmake/3323 "2020-01-13T11:51:05Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@olesenm](https://discourse.paraview.org/u/olesenm)
#### Post date: [January 13, 2020, 11:51am UTC](https://discourse.paraview.org/t/building-plugins-modules-with-paraview-5-7-0-cmake/3323/1 "2020-01-13T11:51:06Z")
Despite some pointers from @Joachim_Pouderoux and references to the [build.md](https://gitlab.kitware.com/paraview/paraview/blob/master/Documentation/dev/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:
```auto
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:
```auto
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
```auto
find_package(ParaView REQUIRED COMPONENTS vtkPVPythonCatalyst)
```
So it appears that I need some different syntax here. The subsequent tests also fail:
```auto
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
---
### Author:  [@utkarsh.ayachit](https://discourse.paraview.org/u/utkarsh.ayachit)
#### Post date: [January 17, 2020, 7:36pm UTC](https://discourse.paraview.org/t/building-plugins-modules-with-paraview-5-7-0-cmake/3323/2 "2020-01-17T19:36:31Z")
cc: @ben.boeckel
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [January 17, 2020, 7:43pm UTC](https://discourse.paraview.org/t/building-plugins-modules-with-paraview-5-7-0-cmake/3323/3 "2020-01-17T19:43:34Z")
> [@olesenm](#):
>
> Specifically, the following bit fails since it cannot find the include/libs:
>
> try\_compile
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.
> [@olesenm](#):
>
> find\_package(ParaView REQUIRED COMPONENTS vtkPVPythonCatalyst)
The right spelling is `PythonCatalyst`. If that succeeds, the target exists and will be usable (spelled `ParaView::PythonCatalyst`).
> [@olesenm](#):
>
> The name of the plugin is used directly withour a `lib` prefix, which seem to prevent regular library loading.
Plugins are not meant to be linked to directly, so the `lib` doesn’t matter.
> [@olesenm](#):
>
> 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` .
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.
> [@olesenm](#):
>
> 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.
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](https://gitlab.kitware.com/paraview/paraview/issues/19470) if you want to keep an eye on it.
---
### Author:  [@olesenm](https://discourse.paraview.org/u/olesenm)
#### Post date: [January 22, 2020, 1:37pm UTC](https://discourse.paraview.org/t/building-plugins-modules-with-paraview-5-7-0-cmake/3323/4 "2020-01-22T13:37:06Z")
Progressing a bit further…
> [@ben.boeckel](#):
>
> 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.
Ok, changing to `OPTIONAL_COMPONENTS` certainly makes for less writing, but does mean some gymnastics for handling different versions. For example,
```auto
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]_
---
### Author:  [@olesenm](https://discourse.paraview.org/u/olesenm)
#### Post date: [January 22, 2020, 8:18pm UTC](https://discourse.paraview.org/t/building-plugins-modules-with-paraview-5-7-0-cmake/3323/5 "2020-01-22T20:18:01Z")
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