SlicerVMTK not building for SlicerPreview on cdash

Community VMTK
1

SlicerVMTK is not building on cdash for SlicerPreview while it does build for SlicerStable. The error messages relate to the VMTK library itself.

FYI, hoping for an investigation.

2

SlicerPreview is now using a version based on VTK 9.4.2 (ENH: Update default VTK version in external project from 9.2 to 9.4 · Slicer/Slicer@01624f0 · GitHub) while SlicerStable 5.8.x is using a version based on VTK 9.2.

See the below VTK commit which change vtkCellLinks::BuildLinks to no longer have an input as warned in the SlicerPreview Windows build of SlicerVMTK. This VTK commit was first part of the VTK 9.3 release.

3

Thank you for the information, at least I know the source of this issue.

4

When Slicer is built with VTK 9.4, in VTK-build/Common/Core/vtkVersionMacros.h, there is

#define VTK_MINOR_VERSION 2

In my former build with VTK 9.2, this file contains:

#define VTK_BUILD_VERSION 20230607

SlicerVMTK could be built with Slicer/VTK9.4 with this patch:

diff --git a/vtkVmtk/ComputationalGeometry/vtkvmtkSimplifyVoronoiDiagram.cxx b/vtkVmtk/ComputationalGeometry/vtkvmtkSimplifyVoronoiDiagram.cxx
index 3ac28f0..ebcad5a 100644
--- a/vtkVmtk/ComputationalGeometry/vtkvmtkSimplifyVoronoiDiagram.cxx
+++ b/vtkVmtk/ComputationalGeometry/vtkvmtkSimplifyVoronoiDiagram.cxx
@@ -195,8 +195,9 @@ int vtkvmtkSimplifyVoronoiDiagram::RequestData(
   //   return 0;
   //   }
   poly->SetPolys(currentPolys);
-  
-#if (VTK_MAJOR_VERSION >= 9 && VTK_MINOR_VERSION >= 0 && VTK_BUILD_VERSION >= 20221108)
+ 
+// #if (VTK_MAJOR_VERSION >= 9 && VTK_MINOR_VERSION >= 0 && VTK_BUILD_VERSION >= 20221108)
+#if (VTK_MAJOR_VERSION >= 9 && VTK_MINOR_VERSION >= 0)
   currentLinks->SetDataSet(poly);
   currentLinks->BuildLinks();
 #else
@@ -296,7 +297,8 @@ int vtkvmtkSimplifyVoronoiDiagram::RequestData(
     // #pragma message "vtkvmtkSimplifyVoronoiDiagram::RequestData not functional. Must be updated based on Kitware/VTK@88efc809a"
     // vtkErrorMacro(<< "!");
     poly->SetPolys(currentPolys);
-#if (VTK_MAJOR_VERSION >= 9 && VTK_MINOR_VERSION >= 0 && VTK_BUILD_VERSION >= 20221108)
+// #if (VTK_MAJOR_VERSION >= 9 && VTK_MINOR_VERSION >= 0 && VTK_BUILD_VERSION >= 20221108)
+#if (VTK_MAJOR_VERSION >= 9 && VTK_MINOR_VERSION >= 0)
     currentLinks->SetDataSet(poly);
     currentLinks->BuildLinks();
 #else

It’s probably not a definite fix, just a hint rather.

VTK_BUILD_VERSION is not being rightly set in vtkVersionMacros.h.

5

If this is a clean build of Slicer rather than incremental build it should be minor version of 4 and build version of 2. The build version is not a date because it is based on a released tag rather than a nightly dev build.

and what is used in SlicerStable 5.8.x:

6

It’s consistent then.

I am doing a clean Slicer build and here is the content of vtkVersionMacros.h in the build tree.

// SPDX-FileCopyrightText: Copyright (c) Ken Martin, Will Schroeder, Bill Lorensen
// SPDX-License-Identifier: BSD-3-Clause
#ifndef vtkVersionMacros_h
#define vtkVersionMacros_h

#include "vtkVersionQuick.h"

/* Note: this file is deliberately both valid C and valid C++. */

#define VTK_BUILD_VERSION 2
#define VTK_VERSION "9.4.1"

#define VTK_SOURCE_VERSION "vtk version " VTK_VERSION

#define VTK_VERSION_NUMBER                                                                         \
  VTK_VERSION_CHECK(VTK_MAJOR_VERSION, VTK_MINOR_VERSION, VTK_BUILD_VERSION)

#endif

Since vtkvmtkSimplifyVoronoiDiagram.cxx is looking for VTK_BUILD_VERSION >= 20221108 in the revision being built, SlicerVMTK build is bound to fail.

This seems to have been addressed in 6c189dd. May be SlicerVMTK should pull a later revision.

7

I built VMTK at 6c189dd6 with the following errors:

CMake Error at /home/arc/src/SlicerExtension-VMTK-SuperBuild9/VMTK-build/CMake/vtkWrapPython.cmake:209 (find_package):
  By not providing "FindPythonLibs.cmake" in CMAKE_MODULE_PATH this project
  has asked CMake to find a package configuration file provided by
  "PythonLibs", but CMake did not find one.

If the changes in CMakeLists introduced by that commit are reverted, VMTK builds fine. Then SlicerVMTK can be built in turn.

This commit (6c189dd6) probably needs the python changes it is expecting and they do not seem to be compatible with Slicer python.

It looks like there might be a need for a SlicerPreview specific branch in the VMTK repository. It won’t be an easy task to maintain SlicerVMTK otherwise.

Or may be there’s some simpler solution.