ITK/Release 4/Modularization/Add an external module (external module): Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
=== Synopsis === | |||
An External Module is distributed outside the ITK main repository, but it could be built into ITK as a module once downloaded into the local copy of ITK source tree. | An External Module is distributed outside the ITK main repository, but it could be built into ITK as a module once downloaded into the local copy of ITK source tree. | ||
=== Organization === | |||
The organization of an External Module should be the same as an Internal Module: | The organization of an External Module should be the same as an Internal Module: | ||
| Line 5: | Line 9: | ||
To build an External Module, users download it into a local copy of ITK source tree under: ''ITK/Modules/External/''. Then simply rerun the CMake step to configure the new External Module together with other enabled ITK modules. | To build an External Module, users download it into a local copy of ITK source tree under: ''ITK/Modules/External/''. Then simply rerun the CMake step to configure the new External Module together with other enabled ITK modules. | ||
==== Adding testing data ==== | |||
Testing data, such an input and baseline images, are typically kept outside of the Git repository to keep the repository small. | |||
The ITK method for handling test data is the [[ITK/Git/Develop/Data#ExternalData | CMake/ExternalData]] method, where MD5 hashes of the data are stored in the repository, then the files corresponding to the hashes are fetched at build time from a list of data servers. These data servers can be an Apache server you have at your webhost, a [http://midasplatform.org/ Midas server], a Dropbox account, an Amazon S3 account, a Rackspace Cloud File account, etc. | |||
=== Make available to the community === | |||
An example is demonstrated in the Lesion Sizing Toolkit: [http://public.kitware.com/LesionSizingKit/index.php/Users/Build_LST_as_ITK_module Lesion Sizing Toolkit Wiki] | An example is demonstrated in the Lesion Sizing Toolkit: [http://public.kitware.com/LesionSizingKit/index.php/Users/Build_LST_as_ITK_module Lesion Sizing Toolkit Wiki] | ||
Once you have your External Module, you can make it available as a [[ITK/Policy_and_Procedures_for_Adding_Remote_Modules| Remote Module]] So it has broader exposure to the ITK community. | Once you have your External Module, you can make it available as a [[ITK/Policy_and_Procedures_for_Adding_Remote_Modules| Remote Module]] So it has broader exposure to the ITK community. | ||
Revision as of 17:32, 14 July 2012
Synopsis
An External Module is distributed outside the ITK main repository, but it could be built into ITK as a module once downloaded into the local copy of ITK source tree.
Organization
The organization of an External Module should be the same as an Internal Module: Add a module (Internal Module)
To build an External Module, users download it into a local copy of ITK source tree under: ITK/Modules/External/. Then simply rerun the CMake step to configure the new External Module together with other enabled ITK modules.
Adding testing data
Testing data, such an input and baseline images, are typically kept outside of the Git repository to keep the repository small.
The ITK method for handling test data is the CMake/ExternalData method, where MD5 hashes of the data are stored in the repository, then the files corresponding to the hashes are fetched at build time from a list of data servers. These data servers can be an Apache server you have at your webhost, a Midas server, a Dropbox account, an Amazon S3 account, a Rackspace Cloud File account, etc.
Make available to the community
An example is demonstrated in the Lesion Sizing Toolkit: Lesion Sizing Toolkit Wiki
Once you have your External Module, you can make it available as a Remote Module So it has broader exposure to the ITK community.
