A summary of the conclusions is:
- for the shared library plugins to work the application needs to be built in shared mode (not static)
- this means that shared library paths must be set before the application is started
- a launcher can do this -- it is a small program that does not have shared library dependencies that sets paths and then executes the main application
Some other nice things the launcher can do:
- since the launcher starts quickly, it can put up a splash screen for user feedback while the main program is loading
- the launcher can catch abnormal termination conditions of the main program and provide user feedback
- the launcher can run arbitrary programs with the exact environment used by the main application (for example, you can run a debugger on Slicer3-real with all the shared libraries resolved, or you can run a shell from which you can run ldd to see the dependencies for a library).
The group decided to adopt the approach used by slicer2, which is based on the starkit/starpack technology for building small, stand alone programs that include a full tcl/tk interpreter.
The code and documentation are in Slicer3/Utilities/Launcher. The actual startup script is Slicer3/launch.tcl.in, which gets configured by cmake into Slicer3-build/lib/launch.tcl.
Usage for the launcher is:
Slicer3 [--launch <program>] [Options...] where: <program> is a program that should be run using the environment settings defined by the launcher (defaults to Slicer3-real) [Options...] are any options to send to <program>
Windows only: Due to the way tcl captures text from subprocesses, text feedback should be sent to cout (stdout) rather than to cerr (stderr). Messages to cerr will be printed out by the launcher after Slicer3-real exits, which may be confusing to the user. Slicer's implementation of vtkErrorMacro, vtkWarningMacro, etc handles this automatically.