Nightly build TESTS failing for extensions with dependencies to other scriptable modules

Hi there,

today I noticed that (for a long time) our extension tests has been failing (generic, but also our custom tests)


Our mpReview extension has a dependency to ‘SlicerDevelopmentToolbox’

As you will notice, there are no dependencies loaded as additional-module-paths in the following cli command:

   /Users/kitware/Dashboards/Nightly/Slicer-0-build/Slicer-build/Slicer \"--no-splash\" \"--testing\" 
\"--launcher-additional-settings\" \"/Users/kitware/Dashboards/Nightly/S-0-E-b/mpReview-build/AdditionalLauncherSettings.ini\" 
\"--no-main-window\" \"--disable-cli-modules\" \"--additional-module-path\" 
\"--additional-module-paths\" \"/Users/kitware/Dashboards/Nightly/S-0-E-b/mpReview-build/lib/Slicer-4.9/qt-scripted-modules\" 
\"--python-code\" \"import slicer.testing; slicer.testing.runUnitTest([\'/Users/kitware/Dashboards/Nightly/S-0-E-b/mpReview-build\', 
\'/Users/kitware/Dashboards/Nightly/S-0-E-b/mpReview\'], \'qSlicermpReviewModuleGenericTest\')\"

Slicer nightly tests just needs to have those additional dependencies loaded for running tests. Otherwise this doesn’t mirror the real world where I need to install an extension from the ExtensionManager where the downloaded extensions (dependencies) automatically get added to the Slicer “Additional module paths”. And after restarting the extension (optimally) works like a charm!

Hope we can find a simple and quick solution for that.

Thanks in advance.

Does your additional launcher settings file contain all the necessary paths?

SlicerDevelopmentToolbox is definitely missing. When building an extension, would this file automatically get extended by the missing dependencies? That’s what I would expect.

The AdditionalLauncherSettings.ini of my local mpReview build looks like the following:






For reference I added a Mantis issue about the same thing
I haven’t figured it out yet either.

1 Like

Oh yeah. When building an extension which depends on other extensions I would assume the AdditionalLauncherSettings.ini to be extended by the dependencies, which probably would fix that issue.

In my case the extension GelDosimetryAnalysis depends on SlicerRT. The problem locally is that the SlicerRT_DIR CMake variable is not set. Instead it gives me this

CMake warning message

CMake Warning at C:/d/Slicer4/Extensions/CMake/SlicerBlockAdditionalLauncherSettings.cmake:48 (MESSAGE):
Dependent extension SlicerRT cannot be found by CMake find_package(),
therefore paths variables cannot be imported from this extension. The
problem can be resolved by generating SlicerRTConfig.cmake by adding
include(${Slicer_EXTENSION_GENERATE_CONFIG}) to the top-level
CMakeLists.txt of the dependent exension.
Call Stack (most recent call first):
C:/d/S4R/Slicer-build/UseSlicer.cmake:281 (include)
CMakeLists.txt:24 (include)

However include(${Slicer_EXTENSION_GENERATE_CONFIG}) is in the top-level CMakeLists, and SlicerRT does generate a SlicerRTConfig.cmake.

If I define SlicerRT_DIR manually, then it works nicely. It’s not done on the factory unfortunately, and this is where I am stuck now. We have a factory machine and was going to take a look at the issue on it, but I haven’t gotten to that point yet.

There is also something wrong here. The attribute name is not split into three depending extensions


Having more than one dependency was causing issues since I didn’t add those dependencies correctly within the CMakeLists.txt.


The following at leasts splits the dependencies into separate CMake attributes

set(EXTENSION_DEPENDS SlicerDevelopmentToolbox DCMQI PETDICOMExtension)

instead of

set(EXTENSION_DEPENDS "SlicerDevelopmentToolbox DCMQI PETDICOMExtension")

My mistake. But it still doesn’t resolve the dependencies. Not sure where find_package() is looking

1 Like

Yep :slight_smile: I reported the same thing to @jcfr but haven’t added a Mantis issue for this one. See screenshot


Oh so if you don’t put them between quotation marks then it works? Thanks!!

1 Like

Don’t put it in quotation marks or separate it with semicolon:

Both work for me:

set(EXTENSION_DEPENDS dependency1 dependency2 dependency3)

set(EXTENSION_DEPENDS "dependency1;dependency2;dependency3")

Right. The template mentions the space separation, so that was fine. However the example “NA” is within quotes, and that made me put them between quotes. Maybe if we remove the quotes from the template or explain this in the same comment, then it’s less error-prone.

1 Like

Additional directories are collected recursively from all extensions that your extension depends on, and added to the additional launcher settings. Does it work until this point?

Without manually specifying SlicerRT_DIR in the GelDosimetryAnalysis CMake, it is not found, see explanation in earlier comment

Adding of _DIR for all required extensions is implemented in SlicerBlockBuildPackageAndUploadExtensions.cmake:

Maybe you could add a couple of MESSAGE prints in this file to see where things go wrong. If everything looks fine then you can go one step further and check if the generated CMake cache file content is correct (contains _DIR and the value is correct). If not, you can add some MESSAGE prints here:

As mentioned in Developer FAQ / Extensions / Can an extension depend on other extensions ?, the build system should build extensions with the expected <ExtensionName>_DIR variables.

This is implemented here:

and here:

mpReview extension has a dependency to ‘SlicerDevelopmentToolbox’

Looking at the description file confirms that.

GelDosimetry dependencies - See

As we can see in the CMakeLists.txt, the dependency is specified as SlicerRT

But looking at the CMakeCache.txt of both extension, the path is not properly set:

kitware@factory-south-ubuntu:~/Dashboards/Nightly/S-0-E-b/mpReview-build$ cat CMakeCache.txt | grep SlicerDevelopmentToolbox_DIR
kitware@factory-south-ubuntu:~/Dashboards/Nightly/S-0-E-b/GelDosimetryAnalysis-build$ cat CMakeCache.txt | grep SlicerRT_DIR

There is definitively a problem.

Also worth noting that the current test check that _DIR variables are effectively set:

The issue are the following:

I’ve fixed this already earlier today (

1 Like

Also pushed a fix to SlicerRT ( SlicerRTConfig.cmake was generated too early (before any modules were configured), so no module paths were added to SlicerRT’s AdditionalLauncherSettings.ini file.