SlicerExtension-VMTK build failing on MacOS 10.12, VTKv9, Qt 5.10

Development
,
1

I’m attempting to build SlicerExtension-VMTK in my Slicer-SuperBuild directory, configuring using CMake 3.11 and using makefiles, and I encounter an error with the VMTK build step:

[  1%] Built target vtkvmtkITK
make[5]: *** No rule to make target `/short/Slicer-SuperBuild/SlicerExtension-VMTK-build/VMTK/vtkVmtk/Utilities/vtkvmtkITK/vtkvmtkITKHierarchy', needed by `vtkVmtk/Utilities/vtkvmtkITK/vtkvmtkITKArchetypeImageSeriesReaderPython.cxx'.  Stop.
make[4]: *** [vtkVmtk/Utilities/vtkvmtkITK/CMakeFiles/vtkvmtkITKPythonD.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [VMTK-prefix/src/VMTK-stamp/VMTK-build] Error 2
make[1]: *** [CMakeFiles/VMTK.dir/all] Error 2
make: *** [all] Error 2

I don’t see any file or directory named vtkvmtkITKHierarchy, so is this an old reference?
Also, I noticed that the script is cloning the VMTK files from gitHub.com/rlizzo/vmtk.git, rather than github.com/vmtk/vmtk.git. Is there a reason for this?
Any help or advice would be appreciated.

2

I just noticed the open issue on the repository. Is there any workaround I can use?

3

Maybe @jcfr can help.

4

It looks like this specific problem I was having related to compiling the VMTK package itself. I cloned the vmtk/vmtk.git master branch, turned off USE_SYSTEM_ITK and USE_SYSTEM_VTK, let it install its own ITK 4.13.0 and VTK 8.1.0, and it was able to complete the compilation. I’m not sure if that’s because of referencing problems, or inability to compile VMTK with VTK 9. I haven’t tried compiling SlicerExtension-VMTK again yet.

Also, @jcfr, I noticed in the Slicer ExtensionsIndex, https://github.com/Slicer/ExtensionsIndex/blob/master/SlicerVMTK.s4ext, you’ve set the repository reference to be your own fork: https://github.com/jcfr/SlicerExtension-VMTK, revision 5013f532b398f7c9a983bdf65a175ec41ce3292a, but you didn’t do a pull request back to vmtk/SlicerExtension-VMTK. Is there a reason for that?

5

repository reference to be your own fork … Is there a reason for that?

The exact reference is this on https://github.com/jcfr/SlicerExtension-VMTK/commits/fix-macos-packaging

I don’t recall the specific. It should probably be integrated back into master.

1 Like
6

turned off USE_SYSTEM_ITK and USE_SYSTEM_VTK

VMTK should definitively build against the VTK and ITK provided by Slicer.

7

VMTK should definitively build against the VTK and ITK provided by Slicer.

Agreed. I couldn’t get it to do that, so I tried building it on its own separately to figure out what the problem was.

8

Also, there are some changes in my fork of VMTK that should be integrated upstream too:

9

Good news is that all my changes made it to vmtk master

1 Like
10

Good news is that all my changes made it to vmtk master

Ok, thanks. Yes, I see them when I look for your commits to vmtk.
Thanks for committing the SlicerExtension-VMTK changes. It looks like External_VMTK.cmake is still referencing your vmtk fork, though. That may be part of the merge conflict git is complaining about.

11

Fantastic, thanks. Should I try compiling this with VTK9, or will I need to re-compile slicer with VTK8?

Ok, I tried it with VTK9, and the VMTK build is still failing in the same place.

12

By configuring the extension using a Slicer build tree built using Qt5, VTKv9 will also be used:

$ echo $Slicer_Qt5_DIR 
/home/jcfr/Projects/Slicer-Qt5-VTK9-Release/Slicer-build

$ cd /tmp
$ git clone git://github.com/vmtk/SlicerExtension-VMTK.git

$ mkdir SlicerExtension-VMTK-build  && cd $_
$ cmake -DSlicer_DIR:PATH=${Slicer_Qt5_DIR} ../SlicerExtension-VMTK
13

Do you get an error like this one:

[  2%] Built target tet
make[5]: *** No rule to make target '/tmp/SlicerExtension-VMTK-build/VMTK/vtkVmtk/Common/vtkvmtkCommonHierarchy', needed by 'vtkVmtk/Common/vtkvmtkMathPython.cxx'.  Stop.
make[5]: *** Waiting for unfinished jobs....
[  3%] Python Wrapping - generating vtkvmtkCommonPythonInit.cxx
CMakeFiles/Makefile2:528: recipe for target 'vtkVmtk/Common/CMakeFiles/vtkvmtkCommonPythonD.dir/all' failed
make[4]: *** [vtkVmtk/Common/CMakeFiles/vtkvmtkCommonPythonD.dir/all] Error 2
make[4]: *** Waiting for unfinished jobs....
14

Yes, that’s the same place mine is failing:

make[5]: *** No rule to make target `/short/testing/SlicerExtension-VMTK-Build/VMTK/vtkVmtk/Utilities/vtkvmtkITK/vtkvmtkITKHierarchy', needed by `vtkVmtk/Utilities/vtkvmtkITK/vtkvmtkITKArchetypeImageSeriesReaderPython.cxx'.  Stop.
make[4]: *** [vtkVmtk/Utilities/vtkvmtkITK/CMakeFiles/vtkvmtkITKPythonD.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [VMTK-prefix/src/VMTK-stamp/VMTK-build] Error 2
make[1]: *** [CMakeFiles/VMTK.dir/all] Error 2
make: *** [all] Error 2

Or close enough, anyway.

15

By configuring the extension using a Slicer build tree built using Qt5, VTKv9 will also be used

I built with Qt5, and VTK9. I think I rebuilt Slicer last week.

Thanks for your help, I appreciate it.

16

The problem seems to be specific to VMTK itself.

I suspect that (1) building VTMTK against VTK9 will also fail and (2) backporting Slicer/CMake/vtkMacroKitPythonWrap.cmake module to VMTK should help address the problem.

1 Like
17

The problem seems to be specific to VMTK itself.

I suspect that (1) building VTMTK against VTK9 will also fail and (2) backporting Slicer/CMake/vtkMacroKitPythonWrap.cmake module to VMTK should help address the problem.

Thanks for investigating. I’m not sure how to backport Slicer/CMake/vtkMacroKitPythonWrap.cmake, but I can add an issue to the VMTK page requesting VTK9 compatibility.

1 Like
18

I can’t find VMTK in the Extensions Manager:

No extensions found for win:64-bit, revision: '27261'. Please try a different combination

Is the error related to this thread?

19

It is. We figured out that the base VMTK package used by the Slicer extension is not able to build with VTK9, which is part of the Slicer build with Qt5. I looked through the nightly build record, and the Slicer VMTK extension has never compiled with the Qt5 SlicerPreview.
http://slicer.cdash.org/index.php?project=SlicerPreview&date=2018-06-12&filtercount=1&showfilters=1&field1=buildname&compare1=63&value1=VMTK
I submitted a feature request on the VMTK repository about VTK9 compatibility, but I think the person that could respond to that is on vacation. Or, for some reason, he hasn’t looked at the repository for two weeks.

1 Like
20

You could add comment to the VMTK pull request at least once a week, to show that it is still a problem that requires attention.

1 Like