# External Module: bypass ITKData
**URL:** https://discourse.itk.org/t/external-module-bypass-itkdata/4202
**Category:** Engineering
**Tags:** cmake
**Created:** [June 11, 2021, 8:04am UTC](https://discourse.itk.org/t/external-module-bypass-itkdata/4202 "2021-06-11T08:04:30Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@LucasGandel](https://discourse.itk.org/u/LucasGandel)
#### Post date: [June 11, 2021, 8:04am UTC](https://discourse.itk.org/t/external-module-bypass-itkdata/4202/1 "2021-06-11T08:04:30Z")
Hi all,
Iβd like to propose [a patch](https://github.com/LucasGandel/ITK/commit/0a6297f185b31f9dc5149bdc895015eea5d36c13) to allow external modules to skip the creation of the ITKData target. We might want to discuss this here first.
The use case is that RTK embeds another external module internally: ITKCudaCommon. While it is possible to have a remote module depending on another remote (i.e building in ITK), the only limitation when building externally is that the inner module (ITKCudaCommon) will create the ITKData target before the top-level module (RTK). Resulting in RTK missing the test data.
I would completely understand if such a patch was rejected, because the right way would be to pull ITKCudaCommon outside of RTK. What do you think @dzenanz ?
@simon.rit FYI
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [June 11, 2021, 2:27pm UTC](https://discourse.itk.org/t/external-module-bypass-itkdata/4202/2 "2021-06-11T14:27:37Z")
> [@LucasGandel](#):
>
> the right way would be to pull ITKCudaCommon outside of RTK
I totally agree with this π Then ITKUltrasound (and maybe some other modules) could optionally depend on ITKCudaCommon.
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [June 15, 2021, 3:00pm UTC](https://discourse.itk.org/t/external-module-bypass-itkdata/4202/3 "2021-06-15T15:00:00Z")
Hi @LucasGandel ,
Thanks for pushing this forward! π
So, when we build ITKCudaCommon as a remote module and RTK as a remote module we do not run into a target conflict, but when we build ITKCudaCommon as a remote module and RTK externally, we run into a target conflict? Or, is RTK trying to use testing data from ITKCudaCommon without also adding the testing data to RTK? If that is the case, can we just also add the testing data to RTK?
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [June 15, 2021, 3:00pm UTC](https://discourse.itk.org/t/external-module-bypass-itkdata/4202/4 "2021-06-15T15:00:20Z")
CC @Stephen_Aylward
---
### Author:  [@simon.rit](https://discourse.itk.org/u/simon.rit)
#### Post date: [June 16, 2021, 10:47am UTC](https://discourse.itk.org/t/external-module-bypass-itkdata/4202/5 "2021-06-16T10:47:27Z")
> [@dzenanz](#):
>
> I totally agree with this π Then ITKUltrasound (and maybe some other modules) could optionally depend on ITKCudaCommon.
At this stage, we have not tried to take ITKCudaCommon out of RTK. If I remember correctly a recent conversation with @LucasGandel, what is blocking us from making it happen is the lack of separate tests for ITKCudaCommon, it is currently being tested via RTKβs tests and we do not have ressources to write a set of independent tests. Should it still be split and submitted to ITK without tests as a remote test? If yes, with which compliance level?
> [@matt.mccormick](#):
>
> So, when we build ITKCudaCommon as a remote module and RTK as a remote module we do not run into a target conflict, but when we build ITKCudaCommon as a remote module and RTK externally, we run into a target conflict? Or, is RTK trying to use testing data from ITKCudaCommon without also adding the testing data to RTK? If that is the case, can we just also add the testing data to RTK?
Not exactly. I believe @LucasGandel is still trying to work with ITKCudaCommon (written as an ITK module) as a subfolder of the RTK repository:
[https://github.com/SimonRit/RTK/pull/415/files#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20aR187](https://github.com/SimonRit/RTK/pull/415/files#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20aR187)
---
### Author:  [@dzenanz](https://discourse.itk.org/u/dzenanz)
#### Post date: [June 16, 2021, 1:41pm UTC](https://discourse.itk.org/t/external-module-bypass-itkdata/4202/6 "2021-06-16T13:41:29Z")
> [@simon.rit](#):
>
> Should it still be split and submitted to ITK without tests as a remote test? If yes, with which compliance level?
I think it should. It would be Compliance Level 2, with some (many?) checkmarks for higher compliance levels.
While we would gradually add tests to that remote over time, it would be good if the module were to be started with at least one test. That would probably make it compliance level 3.
---
### Author:  [@LucasGandel](https://discourse.itk.org/u/LucasGandel)
#### Post date: [June 17, 2021, 7:57am UTC](https://discourse.itk.org/t/external-module-bypass-itkdata/4202/7 "2021-06-17T07:57:30Z")
> Not exactly. I believe @LucasGandel is still trying to work with ITKCudaCommon (written as an ITK module) as a subfolder of the RTK repository:
Right! ITKCudaCommon and RTK are not decoupled for now. Building RTK as as remote builds ITKCudaCommon as a remote as well (everything goes smooth because both itk-module.cmake are found). But building RTK externally forces us to call add\_subdirectory(ITKCudaCommon). This approach works well too, except for test data. We get a target conflict because both modules call ExternalDataAddTarget(ITKData) (in the same project cmake I guess).
I understand this is a ugly use case, and having a standalone ITKCudaCommon module is prefered here. But I think itβs worth discussing this as it could be used to have ITK remote modules splitted into submodules.
> I think it should. It would be Compliance Level 2, with some (many?) checkmarks for higher compliance levels.
I think that would be many checkmarks, but this is a good way to move forward! If compliance level 2 or 3 are acceptable for now, then I can try to pull ITKCudaCommon out of RTK, clean it and add a test.
---
### Author:  [@LucasGandel](https://discourse.itk.org/u/LucasGandel)
#### Post date: [July 12, 2021, 10:28am UTC](https://discourse.itk.org/t/external-module-bypass-itkdata/4202/8 "2021-07-12T10:28:13Z")
FYI, ITKCudaCommon is almost ready to be pulled out of RTK. Everything builds fine with no conflicts at all.
The only thing that needs to be fixed seems to be the install of external modules targets file in ITKModuleExternal.cmake:
- β[AND ${${itk-module}-targets}](https://github.com/InsightSoftwareConsortium/ITK/blob/0c4381bbca1c5595bf397e2d4f2646aaf394a973/CMake/ITKModuleExternal.cmake#L89)β is always evaluated to FALSE on my side
- The [DESTINATION](https://github.com/InsightSoftwareConsortium/ITK/blob/0c4381bbca1c5595bf397e2d4f2646aaf394a973/CMake/ITKModuleExternal.cmake#L90) should be β${ITK\_INSTALL\_PACKAGE\_DIR}/Modules/ **Targets** β
Iβll be happy to create a MR to fix this, but Iβm not sure about the first point.
@matt.mccormick it was introduced in [96b411f](https://github.com/InsightSoftwareConsortium/ITK/commit/96b411fa20665247def0a916abcefdf47f87110a). Do you know if we still want this?