Remote module made of several modules

Engineering
1

I am quite fond of ITK’s module architecture and I am very pleased with RTK’s move to being a remote module. Thank you all for creating this architecture and thank you @LucasGandel for adapting RTK!

Yet, I think that RTK’s architecture could be improved and we are looking for advices. Currently, most of RTK’s code is in the include, src, test and wrapping directories, as expected for an ITK module. There are however 3 submodules in the utilities directory, 2 third parties gengetopt and lp_solve and one ITK module, ITKCudaCommon. But they are currently compiled along RTK and they are not defined as ITK modules, which I think would be preferable. I have the following questions to try to improve this:

  • is there any possibility to let a remote module be a bundle of modules?
  • if not, is there any other option than having four remote module files in ITK to resolve this (instead of, currently, one RTK.remote.cmake)?
  • if not, is this an option or would you suggest to keep it as is? Can a Remote module be a ThirdParty module?

Thanks in advance for your help,
Simon

3 Likes
2

Hi Simon,

It is wonderful that RTK is available in ITK as remote module and Python package – the improved accessibility makes these awesome algorithms have the impact and adoption they deserve!

The community could certainly benefit in general from the ability to use and build on the embedded ITKCudaCommon module :zap: :green_circle:

Improved remote module dependency support will help, as you suggested.

is there any possibility to let a remote module be a bundle of modules?

The modules rely on each other in a dependency graph where a module is a node in the graph. In general, if we want a remote module to depend on other remote modules, it is best managed if each remote module provides a single module, which adds a single node to the graph.

if not, is there any other option than having four remote module files in ITK to resolve this (instead of, currently, one RTK.remote.cmake)?

Yes, this should be possible with some improvements to the CMake module infrastructure. If we have, for example,

RTK depends on CudaCommon

When RTK is enabled with Module_RTK with the current CMake module infrastructure, CudaCommon is not available to be enabled when the infrastructure finds it listed as a dependency in its itk-module.cmake file. And if CudaCommon had additional remote module dependencies in its itk-module.cmake file, they would not be built, etc.

To resolve this, we could add a CMake variable to flag a module as a remote module in ITKRemoteModule.cmake. Then, force fetching of enabled remote modules in ITKModuleEnablement.cmake followed by an update to the module DAG.

1 Like
3

Thanks for your answer Matt.

Ok, this one is probably the most straightforward. It would need a bit of cleaning and a few more tests before submitting it I guess since it’s tested via RTK only currently. But I guess there aren’t any ThirdParty-type remote modules?

If I understand correctly, ITKRemoteModule.cmake could read a list of modules provided by a given remote. I could give it a try but that does not seem straightforward. Do you think it’s preferable in the particular case of RTK? Do you think lpsolve and gengetopt should be separate modules? From the ITK user point of view, I guess it would result in 3 new options: Module_CudaCommon, Module_Gengetopt and Module_LPSolve…

4

Remote modules can depend on other remote modules, e.g. MCI’s tests depend on RLE. Current behavior: if RLE is not enabled, and building tests is enabled, MCI will refuse to configure.

What Matt suggested is improving the build infrastructure so RLE gets enabled transitively as a dependency. And to make RTK follow this approach, the dependencies (CudaCommon, LPSolve etc) would need to be split into their own remote modules.

5

What comes to mind is ITKOpenCL – next todos are to bring in the work of the Elastix team and adapt to clEsperanto. But, at least at first, this will be a module that depends on other modules versus the other way around. This will simply make it easier to consolidate the CI testing and Python packaging specializations on GitHub that are required to deal with OpenCL. At some point in the future, once it has matured or gets to an unmanageable size, it could be split into smaller modules.

The same approach could be taken for ITKCuda, i.e. everything is shoved into the module, including RTKCuda filters at first. In that case the dependency would be: Cuda depends on RTK. Or, RTKCuda depends on CudaCommon and RTK.

Not quite – ITKRemoteModule.cmake could be extended to identify a module as a remote module. This will enable the dependency management system to resolve in a consistent way, keeping things simple and avoiding duplication.

If there are other codes that would like to use lpsolve and gengetopt, it could be worthwhile to break them into modules. However, third party libraries are more work to wrap as modules, and it is fine to just vendor them for now. Factoring an ITKCuda module could have a big impact on the community and open up collaborations.

If we improve the remote module system, the user will have a nice experience: enable the module they want, and the other modules get enabled automatically :-).

1 Like