compiling a private plugin against a super-built ParaView v5.9.1

I have a private reader plugin, which I successfully compile against a ParaView which is not compiled with superbuild, but which includes multiple non-default options such as ospray, VisRTX, etc…
Running cmake (v3.14) on my plugin source code without any additional flags , automatically finds the pathes to all optional stuff like ospray, oidn, VisRTX, etc. and I can compile the plugin just fine.

I now have access to a new computing center where ParaView is already built with Superbuild (with SHARED_LIBS ON) and provided to users with SoftEnv options. The problem I run into is that cmake (v3.14) now asks me for the pathes to all optional stuff (ospray, mpeg, oidn, BLAS, etc), but none of this information is available to generic users. I guess it is embedded in the superbuild process and is not advertized outside. Is there a way around this, some options the ParaView installers can trigger, to enable generic users to compile private plugins against the super-built ParaView?

There is nothing specific to my plugin. I have tried Kitware’s example MyPNGReader and it is asking for all those non-default pathes, which I do not know.

TIA for any pointers.

I believe this goes back to the “relocatable install” stuff. I believe PARAVIEW_RELOCATABLE_INSTALL should be set to false for the ParaView build in the superbuild. However, I don’t see any way to set that from the superbuild.

For now passing -DPARAVIEW_RELOCATABLE_INSTALL=OFF to PARAVIEW_EXTRA_CMAKE_ARGUMENTS cmake option for the superbuild shold do the trick.

@ben.boeckel , suggestions?

Hmm. We add the install prefix of the found ParaView to CMAKE_INSTALL_PREFIX automatically. At least some of these should be working based on that alone, but I suppose some could need even more help. If disabling PARAVIEW_RELOCATABLE_INSTALL does work, a list of the packages that need it would be useful. FWIW, the difference is only an extra file for each of VTK and ParaView in the install tree: {vtk,paraview}-install-package-helpers.cmake. Moving these out of the way will make it relocatable again if you want a quick-and-dirty switch to flip.

To me this is the classis errors you get when building a plugin against paraview build or install dir in the superbuild.

You need to build against install/lib/cmake/paraview-5.9/

Even then, on windows, you can still have some missing path, see there issues:

In any case, you can always check the CMakeCache of the paraview build to recover the values of the cmake options your plugin ask for.

thanks @mwestphal . However, I am already doing what you suggest, i.e. building against install/lib/cmake/paraview-5.9/
and checking the CMakeCache of the paraview build is not an option. I am a generic user. I did not build ParaView itself. I don’t know where the build tree resides. All I have is the path to the install dir.

Then this sound like new issues, but I’ve not seen them

Disabling PARAVIEW_RELOCATABLE_INSTALL has no positive effect. I see that Boost*, embree*, openvkl*, ospray*, etc. are present in ./install/lib/cmake in my build directory, but they are not in my install directory, thus, not available for generic users wanting to compile a plugin.
btw, whatever the value of PARAVIEW_RELOCATABLE_INSTALL (ON or OFF), I don’t see any {vtk,paraview}-install-package-helpers.cmake files. I only see {vtk,paraview}-find-package-helpers.cmake files

Are you looking at the superbuild’s install directory under its build tree or the result from installing the superbuild itself?

I have now managed to compile plugins in two different ways on Cooley:

with the original superbuild ParaView installed (compiled without any RELOCATABLE flag), I am forced to give cmake the following hints:

       -DCMAKE_BUILD_TYPE=RelWithDebInfo \
       -DParaView_DIR=/soft/visualization/paraview/v5.9.1/lib/cmake/paraview-5.9 \
       -DTBB_INCLUDE_DIR=/soft/visualization/paraview/v5.9.1/include/paraview-5.9 \
       -DTBB_LIBRARY_RELEASE=/soft/visualization/paraview/v5.9.1/lib/ \
       -Drkcommon_DIR=/lus/grand/projects/pvdev/cooley/v5.9.1/build/install/lib/cmake/rkcommon-1.5.1 \
       -Dopenvkl_DIR=/lus/grand/projects/pvdev/cooley/v5.9.1/build/install/lib/cmake/openvkl-0.11.0 \
       -DFFMPEG_avcodec_INCLUDE_DIR=/lus/grand/projects/pvdev/cooley/v5.9.1/build/install/include \
       -DFFMPEG_avformat_INCLUDE_DIR=/lus/grand/projects/pvdev/cooley/v5.9.1/build/install/include \
       -DFFMPEG_avresample_INCLUDE_DIR=/lus/grand/projects/pvdev/cooley/v5.9.1/build/install/include \
       -DFFMPEG_avutil_INCLUDE_DIR=/lus/grand/projects/pvdev/cooley/v5.9.1/build/install/include \
       -DFFMPEG_swresample_INCLUDE_DIR=/lus/grand/projects/pvdev/cooley/v5.9.1/build/install/include \
       -DFFMPEG_swscale_INCLUDE_DIR=/lus/grand/projects/pvdev/cooley/v5.9.1/build/install/include \
       -DPython3_INCLUDE_DIR=/lus/grand/projects/pvdev/cooley/v5.9.1/build/install/include/python3.8 \
       -DSILO_INCLUDE_DIR=/lus/grand/projects/pvdev/cooley/v5.9.1/build/install/include \
       -Dnlohmann_json_DIR=/lus/grand/projects/pvdev/cooley/v5.9.1/build/install/lib64/cmake/nlohmann_json \
       -Dospray_DIR=/lus/grand/projects/pvdev/cooley/v5.9.1/build/install/lib/cmake/ospray-2.4.0 \
       -Dembree_DIR=/lus/grand/projects/pvdev/cooley/v5.9.1/build/install/lib/cmake/embree-3.12.0 \
       -DOpenImageDenoise_DIR=/lus/grand/projects/pvdev/cooley/v5.9.1/build/install/lib/cmake/OpenImageDenoise \
       -DlibLAS_DIR=/lus/grand/projects/pvdev/cooley/v5.9.1/build/install/share/cmake/libLAS \
       -DADIOS2_DIR=/lus/grand/projects/pvdev/cooley/v5.9.1/build/install/lib/cmake/adios2 \

with a new superbuild compilation setting PARAVIEW_RELOCATABLE_INSTALL=OFF, things have not improved much. I still have to give the same hints at the exception of the last 5 lines , (i.e. ospray, embree, oidn, libLAS and ADIOS2).

Hrm. The output of --debug-find without these options should help figure out where things are going badly. ParaView should be adding its install prefix to the search path while finding its own dependencies which should be enough for at least:

  • rkcommon
  • openvkl
  • ffmpeg
  • python3
  • nlohmannjson (Why is it in lib64? I’ll make an MR for that at least)

Silo I’m not so sure about. Also, your TBB include directory is wrong (an extra trailing /paraview-5.9).

my TBB include directory is not wrong. This is where the superbuild installs tbb. There is no directory /soft/visualization/paraview/v5.9.1/include/tbb (which is where cmake is looking). Rather, there is a /soft/visualization/paraview/v5.9.1/include/paraview-5.9/tbb directory. So the hitch is in the install process

As far as all the other components, the problem lies in the fact that I have to get them from the build directory (/lus/grand/projects/pvdev ) , whereas they should be placed in the install directory under /soft/visualization/paraview. Otherwise, generic users, who only know of the install folder, cannot configure a plugin.

I have tried again the process of compiling a plugin against the result from installing the superbuild itself with v5.10-RC1, but the symptoms are still the same. It is asking for ospray and all the other things and I don’t know where they are since I don’t have read access to the superbuild’s build tree. I only have access to the final install.