It seems that in SlicerCAT the Python settings file PythonSlicerLauncherSettings.ini->additionalSettingsFilePath (located in d/python-install/bin/) points to the unexistent file: d/slicersources-build/Slicer-build/SlicerLauncherSettings.ini
as I understand it should point to: d/Slicer-build/[SlicerCAT]LauncherSettings.ini
As a result if I simply run PythonSlicer without slicer GUI then I have no initialized paths/env vars.
SlicerCAT built with Slicer main branch at latest git commit 5e6a904aea97578ce91d0c7ebc0d9c2af11472bb
Ubuntu 20.04
Almost the same problem with the SlicerDesignerLauncherSettings.ini.
Let me explain a little bit:
as I understand SlicerCPack.cmake is responsible for building the files SlicerDesignerLauncherSettings.ini and PythonSlicerLauncherSettings.ini.
From the above link you can see ADDITIONAL_SETTINGS_FILEPATH_BUILD "${Slicer_BINARY_DIR}/${Slicer_BINARY_INNER_SUBDIR}/SlicerLauncherSettings.ini" (for both Designer and Python)
Then I go /d/CMakeCache.cmake and I can see: Slicer_BINARY_DIR:STATIC=/home/kerim/Documents/Colada/d/slicersources-build
And in /d/Slicer-Build/CMakeCache.cmake: Slicer_BINARY_DIR:STATIC=/home/kerim/Documents/Colada/d/Slicer-build
Then in the main CMakeLists.txt you can find that Slicer_BINARY_INNER_SUBDIR points to: set(Slicer_BINARY_INNER_SUBDIR Slicer-build)
I believe that is the root of the problem.
When configuring Pythons settings file the var Slicer_BINARY_DIR is set to slicersources-build.
And when configuring the Designer script it is set to Slicer-build dir.
The second point is that for Custom APP SlicerLauncherSettings.ini is renamed to [SlicerCAT]LauncherSetting.ini. Thus it should be renamed within SlicerCPack.cmake function (accept some variable with app name).
App renaming also concerns the LauncherInstall.ini
Please take a look. If I’m right I could work on that
I haven’t been developing SlicerCAT-based applications recently. Maybe @Sam_Horvath or @cpinter can confirm if they can reproduce the issue (and if yes then why it does not impact their workflow). Most likely a fix is needed and it would be useful if you could work on that and submit a pull request.
Hi! It seems you made good progress with investigating the root cause. I think the easiest would be if you submitted a pull request with the solution you find best and we can discuss the details there.
I haven’t encountered these issues because I don’t use PythonSlicer alone, and I launch designer from a normal Slicer build (the widget xml descriptors are the same so any reasonably recent Slicer-launched designer works the same).