Building vtk-9.2.2 with vtkDicom requires running cmake twice

Support
1

Hello,

I tried to build vtk-9.2.2 the other day and ran into a problem when running:

cmake ../ -GNinja -DCMAKE_INSTALL_PREFIX=/opt/VTK-9.2.2 -DBUILD_SHARED_LIBS=false
-DCMAKE_BUILD_TYPE=Release -DVTK_MODULE_ENABLE_VTK_DICOM=YES 
-DVTK_MODULE_ENABLE_VTK_RenderingExternal=YES -DVTK_MODULE_ENABLE_VTK_RenderingExternal=YES
-DVTK_MODULE_ENABLE_VTK_CommonCore=YES -DVTK_MODULE_ENABLE_VTK_CommonDataModel=YES
-DVTK_MODULE_ENABLE_VTK_FiltersCore=YES -DVTK_MODULE_ENABLE_VTK_FiltersSources=YES -DVTK_MODULE_ENABLE_VTK_IOImage=YES
-DVTK_MODULE_ENABLE_VTK_ImagingHybrid=YES -DVTK_MODULE_ENABLE_VTK_InteractionImage=YES
-DVTK_MODULE_ENABLE_VTK_InteractionStyle=YES -DVTK_MODULE_ENABLE_VTK_RenderingContextOpenGL2=YES
-DVTK_MODULE_ENABLE_VTK_RenderingCore=YES -DVTK_MODULE_ENABLE_VTK_RenderingFreeType=YES
-DVTK_MODULE_ENABLE_VTK_RenderingGL2PSOpenGL2=YES -DVTK_MODULE_ENABLE_VTK_RenderingOpenGL2=YES
-DVTK_MODULE_ENABLE_VTK_CommonColor=YES -DVTK_MODULE_ENABLE_VTK_vtkDICOM=YES 
-DUSE_DCMTK=true -DDCMTK_charls_LIBRARY=/usr/lib/x86_64-linux-gnu/libCharLS.so

(added new lines for readability)

I get the error:

CMake Warning:
  Manually-specified variables were not used by the project:

    VTK_MODULE_ENABLE_VTK_vtkDICOM

If I run cmake again the warning is gone and I can use vtkDicom as expected.

Since I am building vtk-9.2.2 automatized I actually don’t want to call cmake twice.
Can someone tell me what I am doing wrong? Is my cmake command wrong? Or is this the desired way of building vtk-9.2.2 with remote modules?

2

You have a duplicate with a typo:

-DVTK_MODULE_ENABLE_VTK_DICOM=YES

and

-DVTK_MODULE_ENABLE_VTK_vtkDICOM=YES

Eliminate the second, and the warning will go away. Even with this warning, you did not need to run cmake twice to have a successful build.

HTH,
Aron

3

Sorry, but that’s not correct. The two modules are two different things:

-DVTK_MODULE_ENABLE_VTK_DICOM=YES enables the VTK “build-in” DICOM module whereas

-DVTK_MODULE_ENABLE_VTK_vtkDICOM=YES enables the external module vtk-dicom.

The build goes through, but the module is not available, thus my project which uses the vtk-dicom headers doesn’t compile.

Btw. might be important: The cmake command worked with version 9.0.2 without problems.

4

The problem is caused because Remote/vtkDICOM.remote.cmake does this:

vtk_fetch_module(vtkDICOM ...)

when it should do this, since vtk.module for vtkDICOM refers to itself as VTK::DICOM:

vtk_fetch_module(DICOM ...)

It’s surprising this discrepancy has existed for so long (ever since vtkDICOM became a remote module, I believe).

So until this is fixed, you will have to continue to set both of those CMake variables and ignore the cmake warning. Or you can locally patch Remote/vtkDICOM.remote.cmake.

1 Like
5

Thanks for your answer @dgobbi !

So I’m wrong in my understanding that VTK_MODULE_ENABLE_VTK_DICOM enables the internal dicom module in vtk? I guess I can cleanup this cmake command a little.

Do you have any explanation why this changed from v9.0.2 to v9.2.2? As I understand, vtkDICOM was already a remote module in 9.0.2, wasn’t it?

6

My understanding is that VTK_MODULE_ENABLE_VTK_vtkDICOM causes cmake to grab the vtkDICOM code via git, and that VTK_MODULE_ENABLE_VTK_DICOM enables the module. So I don’t think you’re wrong.

I don’t think this has changed at all between v9.0 and v9.2, so I can’t explain any differences you’re seeing (I can look into this, but not today unfortunately). Is there any chance that you are using a different version of CMake for your v9.2.2 build as compared to when you were building v9.0.2?