Make DrawEM distribution package friendly

[schuhschuh]

Rolf suggested in the MIRTK chat to enable use of an already existing N4 installation instead of building ITK from scratch. This should be easy to facilitate with a change of the CMakeLists.txt and would shorten build time.

[schuhschuh]

Just looked at the CMakeLists.txt. For what it's worth @soundray, you can at least use an existing ITK installation to build the N4 binary included in Draw-EM to save some build time.

But of course I see the issue of having a duplicate N4 binary in the MIRTK installation PATH. I think the N4 binary build and installed as part of Draw-EM should probably have a different name, such as DrawEM-N4 to not shadow an existing ANTs installation. [besides the option to skip build/installation as part of Draw-EM altogether as suggested]

[soundray]

Thanks Andreas. The background to this is that I have suggested inclusion of DrawEM in the NixOS package of MIRTK. Heads up to @lheckemann who maintains it.

[schuhschuh]

I see, thanks for this additional info. Sounds good to me.

Regarding N4, I think ANTs only contains a program called N4BiasFieldCorrection as part of the Examples folder. Is this one installed as part of the Nix package ants? Otherwise, I think N4 (as most of ANTs) is probably included in ITK 4 now. I wonder if it would be best for Draw-EM to use a custom Python script to execute the N4BiasFieldCorrectionFilter via SimpleITK instead. How would you handle such Python package dependency in Nix?

More generally, I wonder about a few challenges for creating a distribution package for Draw-EM at the moment:

• How to handle data dependencies such as brain atlases (usually expected to be located in source tree).
• Shell scripts may need changes as these refer to configuration files in the source tree. Also, neither these scripts nor the configuration files are being copied to installation at the moment. If these should be included in the distribution package, it would probably be necessary for the names of these Draw-EM commands would be encapsulated in some namespace, e.g., invocation via drawem <script> or mirtk drawem <script> (luckily the latter wouldn't clash with already existing mirtk draw-em binary whose source is in the tools/ folder).

[schuhschuh]

On an additional note, MIRTK extension packages such as Draw-EM can be build out of MIRTK source tree. Meaning, one can first build and install MIRTK with MODULE_DrawEM=OFF (default), and then separately clone and build this DrawEM repository. The FindMIRTK.cmake module included should find the previously installed MIRTK. This would allow for distributions to create separate distribution packages for these, which I would recommend (e.g., mirtk, mirtk-drawem).

[lheckemann]

Regarding N4: how is DrawEM's N4 materially different from ANTs's? Does it even need to exist?

Data dependencies: yes, the data dependencies issue is the next one I ran into — I think the ideal solution here in principle would be for cmake to allow "substituting" ExternalProject sources. That way, no additional work would be necessary on the DrawEM side (and this problem would be solved for all uses of ExternalProject).

Out-of-source-tree build: I didn't realise this! That sounds like a much better solution than bundling everything in with mirtk itself.