search

dgobbi / vtk-dicom

A set of classes for using DICOM in VTK.
BSD 3-Clause "New" or "Revised" License
258 stars 94 forks source link

Missing find_package(dcmtk) in dicom-config.cmake? #232

Open RobertHabrich opened 1 month ago

RobertHabrich commented 1 month ago

Hi.

I have successfully build vtk-dicom with USE_DCMTK enabled. I was now trying to consume the built vtk-dicom library via find_package(dicom REQUIRED) and target_link_libraries(myapp VTK::DICOM) using the cmake scripts installed to {CMAKE_INSTALL_PREFIX}/lib/cmake/dicom-0.8. This currently fails with:

The link interface of target "VTK::DICOM" contains:

    dcmtk::dcmtk

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

It seems like a find_package(dcmtk) is missing? I can make it work by manually calling that on my side beforehand:

find_package(dcmtk REQUIRED)
find_package(dicom REQUIRED)

But it should most likely be done in dicom-config.cmake.in similar to ITK/GDCM (here)?

dgobbi commented 1 month ago

Thanks for the note, I've added DCMTK to dicom-config.cmake. But I still need to update the machinery a bit, I originally wrote the code assuming the now-obsolete "FindDCMTK.cmake".

RobertHabrich commented 1 month ago

Another problem I've run into when trying to integrate the library via find_package into an actual project: The name "dicom" might be a bit too generic. My project also has a static lib called "dicom" and that now clashes, e.g. my find_package(dicom REQUIRED) call is only looking for my own static library.

Have not yet found out the exact underlying problem. My guess is that both my dicom library's binary dir as well as vtk-dicom's {INSTALL_DIR}/lib/cmake/dicom-0.8 directory are in the search path. But I hope that CMake somehow allows me to resolve this for now.

RobertHabrich commented 3 weeks ago

Another problem I've run into when trying to integrate the library via find_package into an actual project: The name "dicom" might be a bit too generic. My project also has a static lib called "dicom" and that now clashes, e.g. my find_package(dicom REQUIRED) call is only looking for my own static library.

Have not yet found out the exact underlying problem. My guess is that both my dicom library's binary dir as well as vtk-dicom's {INSTALL_DIR}/lib/cmake/dicom-0.8 directory are in the search path. But I hope that CMake somehow allows me to resolve this for now.

Forgot to update my ramblings here... our environment is a bit more complex since we are having a bunch of dependencies that are all deployed via conan (incl. vtk-dicom). As suspected above, the conflict was that we have an internal library named "dicom" for which conan generates cmake scripts to find the package. The path to these scripts as well as the path to the vtk-dicom config files is in cmake's prefix path. So when later calling find_package(dicom) stuff is not really going to work out.

My guess is that there is a way to rename the scripts that conan generates for our internal dicom library and avoid the conflict like that. However, I'm actually patching the vtk-dicom provided cmake scripts during deployment (renaming them to "vtk-dicom")...

So in the end there is no real request to change anything in this project here.