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.
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.
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.
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.
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
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-findwithout 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).
Ben,
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.