I have recently developed a simple C++ plugin for Paraview to enable users to visualise files using our in-house filetype (based on HDF5). I had an existing version of Paraview built with Spack which I could use to build my plugin against, however due to issues related to building Paraview with Spack on Ubuntu we are looking to use Superbuild to deploy v5.12.0 across multiple HPC systems. I have tried to do a test of this myself on a workstation (CentOS 7), however I have been unable to build the plugin against the install directory of Paraview - when I do CMake complains of a missing paraview-config.cmake file, which I can see is buried deep in the Superbuild’s build directory. If I try and build against this build directory, I get endless warnings of missing dependencies etc that I can see have been built as part of the Superbuild…
Am I even using the correct workflow here? Should I be building plugins against the install directory, or some other directory?
Thanks - the only reason I ask is because we often have multiple versions of Paraview live at a time in a common location which is accessible to all users, and so we would (ideally) like to be able to provide our plugins for each version, so building against each individual version’s install directory would be convenient.
and so we would (ideally) like to be able to provide our plugins for each version, so building against each individual version’s install directory would be convenient.
Do you want your users to be able to build their own plugin or do you handle plugin compilation yourself for them ?
We have a small team that handles deployment of Paraview and the building of plugins for users - they (the users) don’t do any of the development or deployment. It could be any one of us in that team that builds a new version + the peripherals when we deploy however. Equally, if any of us want to do any development on our plugins between deployments then we also need to be able to build and test them locally. In the past I have used Spack to do this by building Paraview + it’s dependencies and manually specifying the location of the libraries etc by setting my CMAKE_PREFIX_PATH for each, which is a pain.
Then what you should do is to use the shipping mechanism of the ParaView superbuild (using ctest -R cpack) to deploy the relocatable archive for your users, but keep the build/install for your compilation machines that the small team will be able to use to build plugin compatible with the paraview you deploy.
Cool - I think that’s just about where we have landed after discussing internally too (although we were just simply installing, rather than packaging), so I’ll feed this back to everyone else. Unfortunately we are not able to use containers due to security implications, but yes, that would be the ideal situation!
Thanks for all the pointers Mathieu - much appreciated. Have a good week.
I would definitely recommend using the packaging mechanism instead of installing for reliability as this is how the superbuild is used in Kitware continuous integration. That being said, this is fine if it works for you