More and more VTK problems are surfacing for which it is very hard to find the potential VTK patches that we could backport (virtual reality Qt widget, plot marker style issue, etc.). So, it is time to bit the bullet and try to switch to the latest VTK master.
I tried it on Windows, quickly failed with vtkWrappingTools-8.90.lib not found, and asked help on VTK forum (see here).
I’ll use this topic to give updates on my efforts and ask for help.
Makes sense - probably if you fix on windows the solutions should transfer to other platforms, but if you want me to try mac or linux builds let me know.
Yes, it would be great if you could try it on Mac, too. I’ve pushed what I have now to a branch and submitted a pull request: https://github.com/Slicer/Slicer/pull/1252. You can push changes directly to that branch (all maintainers should have write access).
Agreed, the transition to latest VTK is long overdue.
I anticipate the following challenges:
VTK wrapping of external code may have been removed from VTK but it is reimplemented for example in vtkDICOM by David Gobbi: https://github.com/dgobbi/vtk-dicom/blob/master/CMakeLists.txt. It belongs into VTK, since this will be needed by many other libraries, but for now we can copy-paste the solution of vtkDICOM. Probably @jcfr we’ll need your help with this.
vtkOpenVR is a very special case, because it is a remote module with its source code stored in the VTK main repository. This “neither here nor there” state does not make much sense for me, maybe it is like this for Ken’s convenience, and maybe it has been changed since VTK-8.2. I guess it will either become a proper remote module (like spline reslicer or dicom) or a regular built-in VTK module. If it becomes a built-in module we lose the ability to do updates for stable releases and we’ll be forced to ship third-party DLLs with Slicer core. These limitations are tolerable, but it would be better if vtkOpenVR would simply become a remote module.
This problem has been resolved (it was caused by a recent regression in VTK master - now fixed).
Next problem came up during CTK configuration. It was due to VTK_USE_FILE not being generated at all (instead of creating a placeholder file). I’ll implement a check in CTK to only attempt to use the file for old VTK versions.
It seems that vtkWrapPython.cmake and vtkWrapHierarchy.cmake files are gone in VTK-8.90 and it is replaced by vtkModuleWrapPython.cmake, which can wrap complete modules.
@jcfr What do you think would be a good approach? I don’t think we would want to make all Slicer components VTK modules, so vtkModuleWrapPython would not be directly applicable. Should we copy-paste Python wrapper CMake scripts from VTK-8.2 to Slicer and maintain them?
I’ve asked on the VTK forum, too: https://discourse.vtk.org/t/vtkwrappython-disappeared-from-vtk-8-90/2084.
@jcfr We need to make a decision about Python wrapping. Please review the option listed here and add your comments. Thanks!
My continuation of @lassoan’s work can be found in this PR:
There are two errors, neither preventing Slicer build. However, there is an error about not finding a python dll on startup. At least a bit more work is needed.
Thanks for the update 
If I recall, the issue was related to also passing Python3_* variables to external project expecting it. More details at CLI - When module is entered - WidgetRepresentation should be reset to match associated node · Issue #1312 · Slicer/Slicer · GitHub