Combining dcmqi with Conan ITK and DCMTK packages

[akalali]

I'm currently in the process of migrating our code base using Conan for third-party dependency management.
As a test project I use the already existing Conan packages of ITK and DCMTK: I download them from ConanCenter using some Conan-calls inside my CMakeLists.txt and use them to point ITK_DIR and DCMTK_DIR when building dcmqi with CMake's ExternalProject.

However, I'm struggling with different things so I opened an issue here. One main point is that the UseITK.cmake-file is not found / used by the Conan ITK package so dcmqi fails here. I wonder what the use of this file is and why it is necessary.

I would love to bring dcmqi to Conan, but in order to create a Conan recipe file for dcmqi I need to understand the process how dcmqi is built and for that I'm going one step back and try to built dcmqi as an external project, while using Conan packages for its dependencies.

[fedorov]

@jcfr any chance you can comment on this?

[fedorov]

One main point is that the UseITK.cmake-file is not found / used by the Conan ITK package so dcmqi fails here. I wonder what the use of this file is and why it is necessary.

@akalali the purpose of this file appears to be documented here:

https://github.com/InsightSoftwareConsortium/ITK/blob/master/CMake/UseITK.cmake#L13-L16

[akalali]

One main point is that the UseITK.cmake-file is not found / used by the Conan ITK package so dcmqi fails here. I wonder what the use of this file is and why it is necessary.

@akalali the purpose of this file appears to be documented here:

https://github.com/InsightSoftwareConsortium/ITK/blob/master/CMake/UseITK.cmake#L13-L16

I'm wondering if there is another scenario where the source-directory and the UseITK.cmake-file are not existent and only the build-folder (bin, include,lib) can be used for including ITK as a third-party dependency? What will happen in that case with the CMakeLists.txt-file of dcmqi?

[fedorov]

@akalali I am afraid I do not know enough about cmake to answer your question, but I imagine in that scenario you mentioned, the steps performed in UseITK.cmake would need to be performed somewhere else. I do not know if it is a valid scenario though not to have that file, or if its absence indicates incorrect installation of ITK. You may also try asking at the ITK discourse: https://discourse.itk.org/. I think that forum might be the best place to discuss this topic.

[jcfr]

re: useITK

In the context of ITK, the file UseITK.cmake is available in the source directories of master and all releases (e.g v5.1.2).

To ensure, it is available in the ITK install tree (or SDK generated from it), there is also a corresponding install rule:
https://github.com/InsightSoftwareConsortium/ITK/blob/d8f088f2773179b8bce58d18ba656d25cb42999b/CMakeLists.txt#L576-L584

Looking at conan index, ITK version 5.1.0 is downloaded:
https://github.com/conan-io/conan-center-index/blob/master/recipes/itk/all/conandata.yml

As a next step, I suggest to look how the conan package is created.

[akalali]

In the context of ITK, the file UseITK.cmake is available in the source directories of master and all releases (e.g v5.1.2).

Yes, and when I build ITK "the classic CMake" way, the UseITK.cmake file inside the source directory is refered to by the ITKConfig.cmake-file (using the variable ITK_USE_FILE) inside the build directory. The build directory is pointed to by the ITK_DIR (or CMAKE_PREFIX_PATH) while configuring dcmqi. So here everything works as expected.

To ensure, it is available in the ITK install tree (or SDK generated from it), there is also a corresponding install rule:
https://github.com/InsightSoftwareConsortium/ITK/blob/d8f088f2773179b8bce58d18ba656d25cb42999b/CMakeLists.txt#L576-L584

This is interesting: I created my own ITK 4.13.3 Conan recipe for another project (see here) and when I create the package from this recipe, I get the following directory structure:

[] bin
[] include
[] lib
[] share
- conaninfo.txt
- conanmanifest.txt

Inside the lib-directory there is another directory structure

[] cmake
 [] ITK-4.13
  - ITKConfig.cmake
  - UseITK.cmake

Here, the ITKConfig.cmake refers to the UseITK.cmake-file in the same directory.
However, with the conan-center recipe for ITK 5.1.0 I get the following directory structure:

[] bin
[] include
[] lib
[] share
- conaninfo.txt
- conanmanifest.txt

but the lib-directory does neither contain a cmake-directory nor a UseITK.cmake-file. There might be reasons for this because of my setup; I need to investigate on that. But maybe your advise will bring me closer to the solution:

As a next step, I suggest to look how the conan package is created.

I will try to build dmqi with my own ITK 4.13.3 Conan recipe and see if the UseITK.cmake-file can be included.
This will hopefully tell me if my CMake-configuration for this project is wrong or if the conan-center provided recipe does not work as expected.

[akalali]

So what I did was the following:

• use my ITK 4.13.3 Conan recipe from another project to locally create an ITK package
• set ITK 4.13.3 as a requirement for my dcmqi-project
• let Conan automatically find the required ITK package

The result is a ITKConfig.cmake-file created inside my build-directory. There are some conan-related files (conanbuildinfo.cmake, conanbuildinfo.txt) and the ITKTarget-release.cmake-file. All of them point to C:/.conan/0bc323/1/lib/cmake/ which is inside the build directory of my locally created ITK 4.13.3 package with the following directory structure:

[] bin
[] include
[] lib
[] share
- conaninfo.txt
- conanmanifest.txt

Inside the lib.directory is a cmake-directory with a ITK-4.13-directory containing the UseITK.cmake-file. This is equal to what was already highlighted in the previous comment.
However, the dcmqi-build still fails because of the same error:

CMake Error at CMakeLists.txt:275 (include):
  include called with wrong number of arguments.  include() only takes one
  file.

So basically I'm not able to automatically point my dcmqi-project to the correct ITK-build directory or to use the correct ITKConfig.cmake-file.

There is an option to use different CMake generators (e.g. cmake, cmake_find_package, cmake_find_package_multi) which leads to different Conan-configuration output files. I will investigate on that and see if I can get the project working.

At least it is clear now that I might not be pointing to the right ITK-directory and thus the required ITK-files are not found.
However, I still need to find out why the UseITK.cmake-file and the parent cmake-directory is not created in the ITK 5.1.0 case at all.

[akalali]

Wrong button clicked :D
I tried the above workflow with my recipe, but this time I changed the recipe such that ITK v5.1.0 is cloned and built.
I get the same directory structure (with an existing UseITK.cmake-file) as in the ITK v4.13.3 case but again, I don't seem to be able to point my dcmqi project to the correct ITK-build directory or use the correct ITKConfig.cmake-file - such that the existing UseITK.cmake-file is included.

So while there is a problem with the ITK 5.1.0 Conan recipe from conan-center, the general problem of not considering the correct ITK-files still exists.

[fedorov]

I get the same directory structure (with an existing UseITK.cmake-file) as in the ITK v4.13.3 case but again, I don't seem to be able to point my dcmqi project to the correct ITK-build directory or use the correct ITKConfig.cmake-file - such that the existing UseITK.cmake-file is included.

If I understand correctly, you do have the ITKConfig.cmake file, and you do have UseITK.cmake file.

Do you have the ITK_USE_FILE variable defined in your ITKConfig.cmake file?

Does it point to the right location of the UseITK.cmake file?

If the answer to both questions above is yes, perhaps you have multiple installations of ITK on your system, and a different one is being used?

[akalali]

I get the same directory structure (with an existing UseITK.cmake-file) as in the ITK v4.13.3 case but again, I don't seem to be able to point my dcmqi project to the correct ITK-build directory or use the correct ITKConfig.cmake-file - such that the existing UseITK.cmake-file is included.

If I understand correctly, you do have the ITKConfig.cmake file, and you do have UseITK.cmake file.

Do you have the ITK_USE_FILE variable defined in your ITKConfig.cmake file?

Does it point to the right location of the UseITK.cmake file?

If the answer to both questions above is yes, perhaps you have multiple installations of ITK on your system, and a different one is being used?

Ok, so to understand this maybe the principles of Conan need to be know:
What Conan does is it automatically generates a new FindITK.cmake- or ITKConfig.cmake-file, depending on the need of the project. In my case I need the ITKConfig.cmake-file, because dcmqi uses find_package(ITK NO_MODULE REQUIRED) to find ITK (which uses the config mode to find ITK by looking for a <PackageName>Config.cmake-file). This auto-generated config-file does not set the ITK_USE_FILE or include the UseITK.cmake-file.

However, it points to the Conan-built ITK inside my C:\.conan\... directory (the whole idea of Conan here is to have a local C++-package repository (of binaries) that can be re-used by different projects). So ITK (binaries) is found and set and used, but the Conan ITK-package does not consider the UseITK.cmake-file.

So now there are two options, to make things work without the need to patch dcmqi (and I'm pretty sure that the idea of Conan is to integrate easily into existing CMake-projects):

1. do not auto-generate a new ITKConfig.cmake-file but use the existing one in the build-directory of the Conan-built ITK
2. make the Conan ITK recipe be aware that there is a UseITK.cmake-file and that it should somehow be taken into consideration

I think a straight forward solution is 1. I already asked here what the recommended way of doing is. I would basically just say: "I don't need a new ITKConfig.cmake-file, because I know there exists one and I'm pointing you to it".
The problem with that is, that the conan-center provided ITK 5.1.0 recipe does not provide the cmake-directory containing the required files (as already mentioned above in another comment) - but I might have a solution for that as well.

So basically - if you think that include(${ITK_USE_FILE}) inside the dcmqi CMakeLists.txt is absolutely necessary and the recommended way of including ITK, I need to test the proposed options and see if can make everything work by changing the way Conan brings ITK into my project.

[fedorov]

if you think that include(${ITK_USE_FILE}) inside the dcmqi CMakeLists.txt is absolutely necessary and the recommended way of including ITK

dcmqi CMakeLists.txt file was cross-checked by @jcfr from Kitware, who is one of the top experts in CMake on this planet (from what I know, anyway!). Based on that, I am pretty sure that it is the recommended way of including ITK. But if you want to confirm that, I suggest you ask on the ITK forum.

[jcfr]

conan-center provided ITK 5.1.0 recipe does not provide the cmake-directory containing the required files (as already mentioned above in another comment) - but I might have a solution for that as well.

To move forward, I suggest to address this.

Thanks again for your help and patience 🙏

[akalali]

Hi again,

so it seems as

1. do not auto-generate a new ITKConfig.cmake-file but use the existing one in the build-directory of the Conan-built ITK

is actually not an option. The conan-center documentation states that the config-files should not be packaged (see here).
This leaves us with the requirement to let Conan automatically generate its own ITKConfig.cmake-file.

Now we are back at

2. make the Conan ITK recipe be aware that there is a UseITK.cmake-file and that it should somehow be taken into consideration

I addressed this issue and a PR will cover this. The idea is to remove the config-files, as required by the documentation, but leave the UseITK.cmake-file and make Conan aware of this file. This allows us then to define our own ${ITK_USE_FILE} path variable which than can be used inside dcmqi's CMakeLists.txt.

I tried the recipe and now the error is gone.
This leaves me with another error that was already mentioned here (second half of the comment).
I found something striking:

• when I change my Conan-call such that a FindDCMTK.cmake file is generated (instead of a DCMTKConfig.cmake), I apparently need to change dcmqi's CMakeLists.txt to use find_package(DCMTK MODULE REQUIRED) instead of find_package(DCMTK NO_MODULE REQUIRED)
  -> this way the mentioned error does not occur anymore and dcmqi is built as expected

I'm still investigating and maybe one needs to understand the Conan internals but maybe you have an idea why the config-mode does not correctly include the required header files.
Here (second half) I even created a small test-project using only DCMTK and a target that depends on DCMTK. I was able to correctly build everything after I added ${DCMTK_INCLUDE_DIRS_RELEASE} as a target include directory. This is a Conan-generated variable that I would need to somehow inject into dcmqi's CMakeLists.txt, which would make the integration of the Conan packages be intrusive.

[akalali]

The difference in DCMQITargets.cmake between the different approaches:
Using Conan-generated FindDCMTK.cmake, include in dcmqi with find_package(DCMTK MODULE REQUIRED)

set_target_properties(dcmqi PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/include;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/include/dcmtk;C:/.conan/84c73d/1/include/ITK-5.1;C:/Development/GitHub/akalali/build/ep/Source/DCMQI/include;C:/Development/GitHub/akalali/build/ep/Build/DCMQI/include;C:/Development/GitHub/akalali/build/ep/Source/DCMQI/jsoncpp;C:/.conan/84c73d/1/include/vxl/core;C:/.conan/84c73d/1/include/vxl/vcl"
  INTERFACE_LINK_LIBRARIES "C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/i2d.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmjpeg.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/ijg8.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/ijg12.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/ijg16.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmjpls.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/charls.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/cmr.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmwlm.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmpstat.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmtls.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmsr.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmimage.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmdsig.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmqrdb.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmnet.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmrt.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmimgle.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmseg.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmtract.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmpmap.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmfg.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmiod.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/dcmdata.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/oflog.lib;C:/Users/.conan/data/dcmtk/3.6.5/_/_/package/e7e107e6cd35509c9b558bc060f0b7e067b8e481/lib/ofstd.lib;iphlpapi;ws2_32;netapi32;wsock32;itkdouble-conversion;ITKInternalEigen3::Eigen;itksys;itkvnl_algo;itkvnl;itkv3p_netlib;itknetlib;itkvcl;ITKCommon;itkNetlibSlatec;ITKStatistics;ITKTransform;ITKMesh;itkzlib;ITKMetaIO;ITKSpatialObjects;ITKPath;ITKLabelMap;ITKQuadEdgeMesh;ITKFastMarching;ITKIOImageBase;ITKSmoothing;ITKImageFeature;ITKOptimizers;ITKPolynomials;ITKBiasCorrection;ITKColormap;ITKFFT;ITKConvolution;ITKDICOMParser;ITKDeformableMesh;ITKDenoising;ITKDiffusionTensorImage;ITKEXPAT;gdcmDICT;gdcmMSFF;ITKznz;ITKniftiio;ITKgiftiio;ITKPDEDeformableRegistration;hdf5_cpp-static;hdf5-static;ITKIOBMP;ITKIOBioRad;ITKIOBruker;ITKIOCSV;ITKIOGDCM;ITKIOIPL;ITKIOGE;ITKIOGIPL;ITKIOHDF5;itkjpeg;ITKIOJPEG;itkopenjpeg;ITKIOJPEG2000;itktiff;ITKIOTIFF;ITKIOLSM;itkminc2;ITKIOMINC;ITKIOMRC;ITKIOMeshBase;ITKIOMeshBYU;ITKIOMeshFreeSurfer;ITKIOMeshGifti;ITKIOMeshOBJ;ITKIOMeshOFF;ITKIOMeshVTK;ITKIOMeta;ITKIONIFTI;ITKNrrdIO;ITKIONRRD;itkpng;ITKIOPNG;ITKIOSiemens;ITKIOXML;ITKIOSpatialObjects;ITKIOStimulate;ITKTransformFactory;ITKIOTransformBase;ITKIOTransformHDF5;ITKIOTransformInsightLegacy;ITKIOTransformMatlab;ITKIOVTK;ITKKLMRegionGrowing;itklbfgs;ITKMarkovRandomFieldsClassifiers;ITKOptimizersv4;ITKQuadEdgeMeshFiltering;ITKRegionGrowing;ITKRegistrationMethodsv4;ITKTestKernel;ITKVTK;ITKVideoCore;ITKVideoIO;ITKWatersheds;\$<\$<NOT:\$<BOOL:1>>:>"
)

Using Conan-generated DCMTKConfig.cmake, include in dcmqi with find_package(DCMTK NO_MODULE REQUIRED)

set_target_properties(dcmqi PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "C:/.conan/84c73d/1/include/ITK-5.1;C:/Development/GitHub/akalali/build/ep/Source/DCMQI/include;C:/Development/GitHub/akalali/build/ep/Build/DCMQI/include;C:/Development/GitHub/akalali/build/ep/Source/DCMQI/jsoncpp;C:/.conan/84c73d/1/include/vxl/core;C:/.conan/84c73d/1/include/vxl/vcl"
  INTERFACE_LINK_LIBRARIES "itkdouble-conversion;ITKInternalEigen3::Eigen;itksys;itkvnl_algo;itkvnl;itkv3p_netlib;itknetlib;itkvcl;ITKCommon;itkNetlibSlatec;ITKStatistics;ITKTransform;ITKMesh;itkzlib;ITKMetaIO;ITKSpatialObjects;ITKPath;ITKLabelMap;ITKQuadEdgeMesh;ITKFastMarching;ITKIOImageBase;ITKSmoothing;ITKImageFeature;ITKOptimizers;ITKPolynomials;ITKBiasCorrection;ITKColormap;ITKFFT;ITKConvolution;ITKDICOMParser;ITKDeformableMesh;ITKDenoising;ITKDiffusionTensorImage;ITKEXPAT;gdcmDICT;gdcmMSFF;ITKznz;ITKniftiio;ITKgiftiio;ITKPDEDeformableRegistration;hdf5_cpp-static;hdf5-static;ITKIOBMP;ITKIOBioRad;ITKIOBruker;ITKIOCSV;ITKIOGDCM;ITKIOIPL;ITKIOGE;ITKIOGIPL;ITKIOHDF5;itkjpeg;ITKIOJPEG;itkopenjpeg;ITKIOJPEG2000;itktiff;ITKIOTIFF;ITKIOLSM;itkminc2;ITKIOMINC;ITKIOMRC;ITKIOMeshBase;ITKIOMeshBYU;ITKIOMeshFreeSurfer;ITKIOMeshGifti;ITKIOMeshOBJ;ITKIOMeshOFF;ITKIOMeshVTK;ITKIOMeta;ITKIONIFTI;ITKNrrdIO;ITKIONRRD;itkpng;ITKIOPNG;ITKIOSiemens;ITKIOXML;ITKIOSpatialObjects;ITKIOStimulate;ITKTransformFactory;ITKIOTransformBase;ITKIOTransformHDF5;ITKIOTransformInsightLegacy;ITKIOTransformMatlab;ITKIOVTK;ITKKLMRegionGrowing;itklbfgs;ITKMarkovRandomFieldsClassifiers;ITKOptimizersv4;ITKQuadEdgeMeshFiltering;ITKRegionGrowing;ITKRegistrationMethodsv4;ITKTestKernel;ITKVTK;ITKVideoCore;ITKVideoIO;ITKWatersheds;\$<\$<NOT:\$<BOOL:1>>:>"
)

[akalali]

Ok, so I found out that everything is included and linked by using the variables DCMTK_INCLUDE_DIRS and DCMTK_LIBRARIES, which is done here and here.
Now looking at the DCMTKConfig-file, which is normally generated by DCMTK (can be found inside the DCMTK-build directory), I find something like
list(APPEND DCMTK_INCLUDE_DIRS "C:/Development/3rdparty/DCMTK/src/ofstd/include") and set(DCMTK_LIBRARIES "ofstd;oflog;dcmdata;i2d;.....

However, these variables are not defined inside the Conan-generated DCMTKConfig.cmake-file. Here a variable CONAN_INCLUDE_DIRS_DCMTK is defined, which points to the include directory of the library package.
Using this variable to set -DDCMTK_INCLUDE_DIRS:PATH=${CONAN_INCLUDE_DIRS_DCMTK} as a parameter for ExternalProject_Add(DCMQI works and leads to a successful build of DCMQI as an external project.

Phew.. the only thing that is unclear is the DCMTK_LIBRARIES - it is still empty and currently I don't find an equivalent variable (list of libraries) defined by Conan.
What would be the best option to test if everything is built correctly?
At least opening DCMQI.sln and building RUN_TESTS gives the following output:

1>------ Build started: Project: ZERO_CHECK, Configuration: Debug x64 ------
1>Checking Build System
2>------ Build started: Project: RUN_TESTS, Configuration: Debug x64 ------
2>Test project C:/Development/GitHub/akalali/build/ep/Build/DCMQI
2>      Start  1: jsonlint_bmmr-example
2> 1/26 Test  #1: jsonlint_bmmr-example ............................................   Passed    0.09 sec
2>      Start  2: jsonlint_pm-example-float
2> 2/26 Test  #2: jsonlint_pm-example-float ........................................   Passed    0.06 sec
2>      Start  3: jsonlint_pm-example
2> 3/26 Test  #3: jsonlint_pm-example ..............................................   Passed    0.06 sec
2>      Start  4: jsonlint_pm-example_no_modifier
2> 4/26 Test  #4: jsonlint_pm-example_no_modifier ..................................   Passed    0.06 sec
2>      Start  5: jsonlint_seg-example
2> 5/26 Test  #5: jsonlint_seg-example .............................................   Passed    0.06 sec
2>      Start  6: jsonlint_seg-example_multiple_segments
2> 6/26 Test  #6: jsonlint_seg-example_multiple_segments ...........................   Passed    0.07 sec
2>      Start  7: jsonlint_seg-example_multiple_segments_reordered
2> 7/26 Test  #7: jsonlint_seg-example_multiple_segments_reordered .................   Passed    0.09 sec
2>      Start  8: jsonlint_sr-tid1500-ct-liver-example
2> 8/26 Test  #8: jsonlint_sr-tid1500-ct-liver-example .............................   Passed    0.06 sec
2>      Start  9: jsonlint_sr-tid1500-example-nan
2> 9/26 Test  #9: jsonlint_sr-tid1500-example-nan ..................................   Passed    0.06 sec
2>      Start 10: jsonlint_sr-tid1500-example
2>10/26 Test #10: jsonlint_sr-tid1500-example ......................................   Passed    0.06 sec
2>      Start 11: jsonlint_sr-tid1500-qualitative
2>11/26 Test #11: jsonlint_sr-tid1500-qualitative ..................................   Passed    0.06 sec
2>      Start 12: jsonlint_pm-dce-context
2>12/26 Test #12: jsonlint_pm-dce-context ..........................................   Passed    0.06 sec
2>      Start 13: jsonlint_pm-dwi-context
2>13/26 Test #13: jsonlint_pm-dwi-context ..........................................   Passed    0.06 sec
2>      Start 14: jsonlint_anatomic-context-schema
2>14/26 Test #14: jsonlint_anatomic-context-schema .................................   Passed    0.06 sec
2>      Start 15: jsonlint_common-schema
2>15/26 Test #15: jsonlint_common-schema ...........................................   Passed    0.06 sec
2>      Start 16: jsonlint_pm-context-schema
2>16/26 Test #16: jsonlint_pm-context-schema .......................................   Passed    0.06 sec
2>      Start 17: jsonlint_pm-schema
2>17/26 Test #17: jsonlint_pm-schema ...............................................   Passed    0.06 sec
2>      Start 18: jsonlint_seg-schema
2>18/26 Test #18: jsonlint_seg-schema ..............................................   Passed    0.05 sec
2>      Start 19: jsonlint_segment-context-common-schema
2>19/26 Test #19: jsonlint_segment-context-common-schema ...........................   Passed    0.05 sec
2>      Start 20: jsonlint_segment-context-schema
2>20/26 Test #20: jsonlint_segment-context-schema ..................................   Passed    0.06 sec
2>      Start 21: jsonlint_sr-common-schema
2>21/26 Test #21: jsonlint_sr-common-schema ........................................   Passed    0.06 sec
2>      Start 22: jsonlint_sr-tid1500-schema
2>22/26 Test #22: jsonlint_sr-tid1500-schema .......................................   Passed    0.05 sec
2>      Start 23: jsonlint_AnatomicRegionAndModifier-DICOM-Master
2>23/26 Test #23: jsonlint_AnatomicRegionAndModifier-DICOM-Master ..................   Passed    0.06 sec
2>      Start 24: jsonlint_SegmentationCategoryTypeModifier-DICOM-Master
2>24/26 Test #24: jsonlint_SegmentationCategoryTypeModifier-DICOM-Master ...........   Passed    0.07 sec
2>      Start 25: jsonlint_SegmentationCategoryTypeModifier-SlicerGeneralAnatomy
2>25/26 Test #25: jsonlint_SegmentationCategoryTypeModifier-SlicerGeneralAnatomy ...   Passed    0.06 sec
2>      Start 26: jsonlint_SegmentationCategoryTypeModifier
2>26/26 Test #26: jsonlint_SegmentationCategoryTypeModifier ........................   Passed    0.06 sec
2>
2>100% tests passed, 0 tests failed out of 26
2>
2>Label Time Summary:
2>jsonlint    =   1.62 sec*proc (26 tests)
2>
2>Total Test time (real) =   1.66 sec
========== Build: 2 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

[jcfr]

Thanks for the update. Great progress.

The conan-center documentation states that the config-files should not be packaged (see here).

For simple project, this approach may work ... but for more complex project. This means that packages would have to be updated to work with conan. This could be done by maintaining a set of patches hard-coding values where needed.

Phew.. the only thing that is unclear is the DCMTK_LIBRARIES - it is still empty and currently I don't find an equivalent variable (list of libraries) defined by Conan.

This is set to the list of targets available in the current build of DCMTK. See https://github.com/DCMTK/dcmtk/blob/1d98cfd0fe0748a065b9b91bf957862868c63fd7/CMake/DCMTKConfig.cmake.in#L14

A conan specific patches could probably be applied to hardcode the list

What would be the best option to test if everything is built correctly?

There are around 90 tests total (see here) ... it looks like not all prerequisites are available.