Race condition in linux build

Building fresh with yesterday’s git checkout on a Ubuntu 24.04 machine I got the following repeatably with make -j8. However when I tried to narrow it down with plain make the build succeeded and the program runs fine. I’m guessing this is some kind of race condition because the Transforms module depends on Markups?

Does it happen on for others? My mac builds from a few days ago are fine (using June 2 checkout so with python3.12).

...
[ 24%] Built target vtkSlicerAnnotationsModuleMRMLHierarchy
[ 24%] For vtkSlicerTransformsModuleLogic - updating vtkSlicerTransformsModuleLogicHierarchy.txt
[ 24%] Generating Python wrapper sources for vtkMRMLSceneViewNode
vtkWrapHierarchy: couldn't open file /media/share/tms-work/slicer/Slicer-superbuild/Slicer-build/vtkSlicerMarkupsModuleMRMLHierarchy.txt
make[5]: *** [Modules/Loadable/Transforms/Logic/CMakeFiles/vtkSlicerTransformsModuleLogicHierarchy.dir/build.make:77: Modules/Loadable/Transforms/Logic/vtkSlicerTransformsModuleLogicHierarchy.stamp.txt] Error 1
make[4]: *** [CMakeFiles/Makefile2:8746: Modules/Loadable/Transforms/Logic/CMakeFiles/vtkSlicerTransformsModuleLogicHierarchy.dir/all] Error 2
make[4]: *** Waiting for unfinished jobs....
[ 24%] Generating Python wrapper sources for vtkMRMLSceneViewStorageNode
[ 24%] Generating Python wrapper sources for vtkMRMLScriptedModuleNode
...

Hello @pieper. I’ve never experienced anything like this. Have you tried Ninja? I can give a try in Ubuntu 25.04 tomorrow.

Thanks for checking. No, I haven’t tried ninja for this.

Looks like the preview build failed last night with some github glitch. I’m able to download the file that it says it couldn’t. So maybe tomorrow we’ll see what the dashboard shows. I believe it uses make.

https://slicer.cdash.org/viewBuildError.php?buildid=3830826

I am wondering if this is a side effect of:

  • PR-8464: COMP: Move vtkSlicerCLIModuleLogic from Base/QTCLI to Base/Logic
  • PR-8475: COMP: Fix macOS build removing obsolete VTK wrapping of qSlicerBaseQTCLI

The Linux (‘metroplex’) factory uses ninja[1]:


  1. https://github.com/Slicer/DashboardScripts/blob/091a5e2b6571b34b412de6e92baa6927199dda9d/metroplex-slicer_preview_nightly.cmake#L20 ↩︎

Thanks @jcfr. Yes, it could be related to moving the logic code, but the error message looks like it comes from the wrapping, so I’m not sure.

If everything works with ninja maybe we should make it the default and update the documentation suggesting not to use make. I know some people like to say that if it’s not tested it’s probably broken, so having our instructions match our testing might simplify our lives.

I’m trying a ninja build now to see what happens.

I did a clean build today on Arch Linux with make -j24 and it completed in a single step.

Transitioning to Ninja as our default CMake generator on Linux would require more work as Unix Makefiles is currently used as the default[1] one for building all extensions.

The fact Ninja is used was done out of convenience to easily split[2] the build-system to allow support continuous integration without having to rebuild everything.


  1. https://github.com/Slicer/DashboardScripts/blob/091a5e2b6571b34b412de6e92baa6927199dda9d/metroplex-slicerextensions_preview_nightly.cmake#L18 ↩︎

  2. https://github.com/Slicer/SlicerDocker/blob/a66255f354cace3511a1a1c5047c398f2f605233/slicer-base/Dockerfile#L30-L33 ↩︎

My build with ninja worked with no problem, of course so do some make builds, so it’s hard to know for sure. I guess we’ll just need to keep our eye open for it.