View Issue Details

IDProjectCategoryView StatusLast Update
0004183Slicer4Core: Extensionspublic2016-05-03 14:15
ReporterjcfrAssigned Tojcfr 
PrioritynormalSeverityminorReproducibilityhave not tried
Status assignedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0004183: Specifying additional module path should update launcher settings



When specifying additional module paths, the corresponding launcher settings are not automatically generated.

For modules ...

  • having no additional dependency (beside of the usual Slicer libraries)
  • used from a build tree with RPATH
    .. this will not be a problem.

But for the more general case, this will be a problem.

Currently, launcher settings are automatically updated only by installing an extensions [2]. Process is documented here

When installing extensions the regular launcher settings file named "SlicerLauncherSettings.ini" is updated.

Additional Launcher Settings

To support testing of extensions having libraries and python module living outside of the regular Slicer build or install tree, a custom target named "ConfigureAdditionalLauncherSettings" is added, it is always built and will generate a file named "AdditionalLauncherSettings.ini" in the extension build directory.

The target is added in "Extensions/CMake/SlicerBlockAdditionalLauncherSettings.cmake", it sets two variables:

  • Slicer_ADDITIONAL_LAUNCHER_SETTINGS_FILE: Path to AdditionalLauncherSettings.ini
  • Slicer_ADDITIONAL_LAUNCHER_SETTINGS: sets to "--launcher-additional-settings ${Slicer_ADDITIONAL_LAUNCHER_SETTINGS_FILE}

These variables are then used in macro like "slicer_add_python_test" or "slicer_add_python_unittest" where the command executed ends up like "/path/to/Slicer" --launcher-additional-settings "/path/to/AdditionalLauncherSettings.ini" "/path/to/".

Since in a build tree, "/path/to/Slicer" point to a launcher and not the "real" Slicer executable, the argument "--launcher-additional-settings" will be "swallowed" by the launcher to update the setting prior starting the real executable.

Proposed changes

Teach the launcher to understand:
(1) additional module path command line arguments
(2) "additional module path" settings

To support (1) or (2), the code inferring what should be the "library paths", "paths" and "python paths" associated with a module needs to be available to

  • the "ExtensionManagerModel" when installing an extension and
  • the launcher when processing the "additional-module-path" setting or command line before starting the real Slicer executable.

An idea would be to factor out from the extensions manager model the code computing the paths so that it can be included in the launcher executable.

Challenge: Currently the launcher is a generic application that is pre-compiled and not specific to Slicer:

  • How do we allow integration of Slicer specific requirements into the launcher ?
  • Do we create a fork and integrate our changes ?


Why paths need to be setup before start the real executable ?

On unix, the library loaded only check LD_LIBRARY_PATH at startup time and will ignore change to the value after the program is started. See

On windows, answering the question unambiguously requires some more investigation. A starting point is

TagsNo tags attached.


related to 0002779 resolvedjcfr Mechanism to keep track of the installed extensions across version 


There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2016-05-03 13:33 jcfr New Issue
2016-05-03 13:33 jcfr Status new => assigned
2016-05-03 13:33 jcfr Assigned To => jcfr
2016-05-03 14:10 jcfr Description Updated View Revisions
2016-05-03 14:14 jcfr Description Updated View Revisions
2016-05-03 14:15 jcfr Relationship added related to 0002779