View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004183 | Slicer4 | Core: Extensions | public | 2016-05-03 13:33 | 2016-05-03 14:15 |
Reporter | jcfr | Assigned To | jcfr | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | assigned | Resolution | open | ||
Product Version | |||||
Target Version | Fixed in Version | ||||
Summary | 0004183: Specifying additional module path should update launcher settings | ||||
Description | BackgroundOverviewWhen specifying additional module paths, the corresponding launcher settings are not automatically generated. For modules ...
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 http://slicer-devel.65872.n3.nabble.com/Extensions-and-paths-tt4027050.html#a4027104 When installing extensions the regular launcher settings file named "SlicerLauncherSettings.ini" is updated. Additional Launcher SettingsTo 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:
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/scripts.py". 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 changesTeach the launcher to understand: 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
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:
FAQWhy 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 http://stackoverflow.com/questions/1178094/change-current-process-environment On windows, answering the question unambiguously requires some more investigation. A starting point is https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx#search_order_for_desktop_applications | ||||
Tags | No tags attached. | ||||
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 |