https://github.com/MITK/MITK/pull/124

Doesn't work out of the box (anymore?). I wasn't able to configure MITK when I built the superbuild with an external DCMTK. DCMTK_ROOT was empty on the MITK level and DCMTK_DIR was set to NOTFOUND.

Any update on this, @espak?

It doesn't work. Removing all the special DCMTK CMake handling including the custom FIndDCMTK worked for me. CMake ships a working FindDCMTK.

Pushed new branch T19442-RelyOnCMakesFindDCMTKScript.

Does this work for you guys?

It was not working that time (v2015.05.2) because of the reason I detailed above. I did not try it again with the current master.

@weihs

Which version of CMake has a good FindDCMTK.cmake? Or which version you use?
Do you also have an external application based on MITK?

If FindDCMTK.cmake can be removed from the MITK sources that is good, because it is simpler, but I do not think that it resolves the problem. I think, the problem was not not in FindDCMTK.cmake but in DCMTKConfig.cmake (in the DCMTK install folder) that overwrote the DCMTK_DIR variable.

If you upgraded DCMTK since 2015.05.2 then the new version may provide a good DCMTKConfig.cmake. Then, the best would be to use config mode everywhere.

Sorry, my last comment was not on your new patch.

I see that the master has a new patched version of DCMTK, 3.6.1_20160216, while v2015.05.2 had 3.6.1_20121102. I think, if it installs a correct DCMTKConfig.cmake then your change is good because it simplifies things, but it does not really address the original problem as such.

The error came not in the MITK build, that went fine. The problem was that the DCMTK_DIR in the generated MITKConfig.cmake was incorrect, and it caused problem when configuring an external application based on MITK.

But I will give it a try anyway and let you know how it goes.

I cannot really test it, since we use a snapshot of mitk which is a few months old now. But I compared the diffs and it's nearly the same. I left behind a

if(MITK_USE_DCMTK)
find_package(DCMTK REQUIRED)
endif()

in MITKConfig.cmake.in and CMakeLists.txt. Not sure if that's necessary though.

I tried this with at least CMake 3.6 and 3.7 and DCMTK-3.6.1_20161102, DCMTK-3.6.1_20160630 and DCMTK-3.6.1_20160216. And yes, we use MITK as external dependency.

And just to mention it, I have pretty much the same problems with Eigen and boost. If I build those libraries separately and tell the MITK superbuild to use them as external projects instead of building them again, the MITK-build fails to find Eigen and our application fails to find Eigen and boost. I attached a patch which works for me

Are you sure that this is the right patch? I do not see any reference to boost or eigen.

Yes, MITKConfig.cmake overwrites some boost variables as well, so what we do is that we save the values before finding MITK and then restore the saved values. Something like this:

set(_boost_root ${BOOST_ROOT})
set(_mitk_use_boost ${MITK_USE_Boost})
set(_mitk_use_system_boost ${MITK_USE_SYSTEM_Boost})
set(_mitk_use_boost_libraries ${MITK_USE_Boost_LIBRARIES})
set(_mitk_legacy_export_macro_name ${MITK_LEGACY_EXPORT_MACRO_NAME})

find_package(MITK REQUIRED)
if(MITK_FOUND)
  message("Found MITK")
  set(CMAKE_MODULE_PATH
    ${MITK_SOURCE_DIR}/CMake
    ${CMAKE_MODULE_PATH}
  )
  link_directories(${MITK_LINK_DIRECTORIES})
endif(MITK_FOUND)
    
set(BOOST_ROOT ${_boost_root})
set(MITK_USE_Boost ${_mitk_use_boost})
set(MITK_USE_SYSTEM_Boost ${_mitk_use_system_boost})
set(MITK_USE_Boost_LIBRARIES ${_mitk_use_boost_libraries})
set(MITK_LEGACY_EXPORT_MACRO_NAME ${_mitk_legacy_export_macro_name})

Ya sorry, was the wrong patch. I edited my previous post.