I am developing a new feature in the VolumeRendering module which involves some changes in VTK and I’m looking for the simplest way to build Slicer in that context.
My first instinct was to super-build Slicer, go to the VTK directory and checkout my own branch of VTK (which is ahead of the gitlab kitware vtk by a few commits) and rebuild only VTK, then Slicer. However, it seems the CMake cache of both VTKs is not compatible. The problem could be caused by the introduction of the new module system in VTK which I believe happened between the Slicer head and the gitlab.kitware head.
What is the easiest way to build my own VTK to be compatible with Slicer. There are quite a lot of parameters set in SuperBuild/External_VTK.cmake. Are they all needed? Is there a shortcut that would save me some time? What are your tricks? @lassoan @cpinter @pieper
For any external project, you can pass the options:
For VTK, you can configure Slicer passing:
That said, considering VTK updated its build system in a backward incompatible way, it may not word as smoothly as you would expect …
Yes, unfortunately it may take a while to adapt Slicer to VTK’s new module system. In the mean time it’s probably easier to maintain your patches in a fork of github.com/Slicer/VTK (and point your superbuild there) using the parameters Jc described.
Sounds good. I can backport the changes I made to VTK into a fork of the github.com/Slicer/VTK repository to continue working.
But, what is the best course of action to propagate the changes forward? I’ve already submitted a merge request to VTK. Should I keep pushing them to merge it right away? Or should I try to merge the changes in github.com/Slicer/VTK and then someone else will take care of merging this back to the official VTK?
Ultimately you should make sure the changes are integrated in VTK proper , then we can easily backport into Slicer.