# PARAVIEW\_USE\_EXTERNAL\_VTK broken
**URL:** https://discourse.paraview.org/t/paraview-use-external-vtk-broken/13956
**Category:** Development
**Created:** [February 16, 2024, 5:35pm UTC](https://discourse.paraview.org/t/paraview-use-external-vtk-broken/13956 "2024-02-16T17:35:37Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@biddisco](https://discourse.paraview.org/u/biddisco)
#### Post date: [February 16, 2024, 5:35pm UTC](https://discourse.paraview.org/t/paraview-use-external-vtk-broken/13956/1 "2024-02-16T17:35:37Z")
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.]
Can anyone comment on the external\_vtk problem?
thanks
JB
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [February 16, 2024, 6:07pm UTC](https://discourse.paraview.org/t/paraview-use-external-vtk-broken/13956/2 "2024-02-16T18:07:04Z")
> [@biddisco](#):
>
> 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?
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](https://gitlab.kitware.com/paraview/paraview/-/merge_requests/6375).
> [@biddisco](#):
>
> [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.]
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.
> [@biddisco](#):
>
> 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.
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).
---
### Author:  [@biddisco](https://discourse.paraview.org/u/biddisco)
#### Post date: [February 16, 2024, 7:42pm UTC](https://discourse.paraview.org/t/paraview-use-external-vtk-broken/13956/3 "2024-02-16T19:42:26Z")
Ben
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!
JB
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [February 16, 2024, 9:00pm UTC](https://discourse.paraview.org/t/paraview-use-external-vtk-broken/13956/4 "2024-02-16T21:00:57Z")
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).