Documentation/4.4/Developers/Build system/Remote Module

Purpose of Remote Modules

Keep the Slicer core lean.

Allow individuals or organizations to work on their own private modules and optionally make these modules available to the Slicer users without the need to use the extensions manager.

Policy for Adding Remote Modules

Module is known to compile on Linux, MacOSX and Windows.

Module is tested.

Module is documented on the wiki.

Module names must be unique.

At no time in the future should a module in the main Slicer repository depend on Remote module.

Remote modules MUST define a specific unique revision (git hash or svn revision). It is important for debugging and scientific reproducibility that there be a unique set of code associated with each slicer revision.

Procedure for Adding a Remote Module

1. Discuss with Slicer core Developers

2. Add an entry into SuperBuild.cmake using Slicer_Remote_Add() macro. For example:

   Slicer_Remote_Add(Foo
     GIT_REPOSITORY ${git_protocol}://github.com/john/foo
     GIT_TAG abcdef
     OPTION_NAME Slicer_BUILD_Foo
     LABELS REMOTE_MODULE
     )
   list_conditional_append(Slicer_BUILD_Foo Slicer_REMOTE_DEPENDENCIES Foo)
   

3. Corresponding commit message should be similar to:

   ENH: Add Foo remote module
   
   The Foo module provide the user with ...
   

As a side effect of calling Slicer_Remote_Add, the option Slicer_BUILD_Foo will automatically be added as an advanced option and (2) the CMake variables Slicer_BUILD_Foo and Foo_SOURCE_DIR will be passed to Slicer inner build.

Additionally, by specifying the REMOTE_MODULE label, within Slicer/Modules/Remote/CMakeLists.txt, the corresponding source directory will automatically be added using a call to add_directory.

Procedure for Updating a Remote Module

1. Update the entry into SuperBuild.cmake

2. Commit with a message similar to:

ENH: Update Foo remote module

$ git shortlog abc123..efg456
John Doe (2):
  Add support for ZZZ spacing
  Refactor space handler to support multi-dimension