`PythonSlicerLauncherSettings.ini` points to wrong `additionalSettingsFilePath`

Hi,

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.

1 Like

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).

Thanks!

1 Like

PR is created