I’m setting up builds of paraview on a new grace-hopper machine and having some problems.
The build system is built around spack installations of packages for everything.
In order to use vtk-m, I need to use the latest VTK which is compiling ok and I’ve added some options to the spack package to enable EGL and suchlike. All is good here.
However, the paraview cmake is ignoring PARAVIEW_USE_EXTERNAL_VTK and using the bundled VTK.
I’d like to fix this, but before I do, can anyone tell me why the external_vtk option was not supported - I presume that nobody else is using it?
I’d also like to have a VTK_USE_EXTERNAL_VTKM option and allow an unbundled vtk-m library to be pullled in. spack handles this rather well and I’m happy to make the changes. I have modifed the paravciew spack to take an external vtk, but the cmake needs some changes too.
[To be honest, the entire vtk/Thirdparty folder needs to be overhauled - almost everything there can be installed via spack and the technical debt keeping all the version checks in the vtk cmake is painful to look at. There are h5part things left in there that I added in about 2010 and frankly they should be removed in favour of a spack installed library and a simple check in vtk - if not found, disable the filters that need it. End of story.]
The build system rewrite was designed with external VTK in mind. However, implementing it in practice is a development process disruption to ParaView (as VTK releases are not often enough to rely upon). So the status quo was kept but the wires for actually doing it capped and stuffed back into the junction box (so to speak). @danlipsa is working on finishing the wiring. There were some VTK loose ends that need addressed, but work is progressing. See this MR.
I agree with this, however not everyone uses Spack (and I certainly don’t want to tie VTK to Spack-only as a provider either). Also note that any dependency not vendored in ThirdParty/ (except those supported by PyPI such as OpenGL, X11, and the like) is not supported in the official vtk wheel package on PyPI. If there are packages where external support is lacking and you’d like to use it, support for external copies is certainly welcome.
I thought there was an issue for this, but I can’t find it. Please do so (so that you’re involved in any discussion as well). Cc: @berkgeveci because we talked about external VTK-m years ago and it wasn’t of any priority at the time. Note that we should also mangle our internal VTK-m as well for completion’s sake (but these tasks don’t have to be tied to each other).
Thanks - I will check the PR you linked. And yes - I didn’t mean to imply that users would have to use spack, but duplicating alll that code in the thirdparty folder is something that needs to be stopped!
While I am definitely receptive to the “VTK ships too many third party libraries”, the higher bar I’ve put on inclusion (mangling, build system integration, etc.) has not stopped the flow (but there have been some that have been discouraged at least, so there are fewer than there would be otherwise).