March 24, 2018: Nightly build manually re-triggered after fixing regression due to rename of vtkNRRDReader, vtkNRRDWriter to vtkTeemNRRD{R,W}

Development
1

What happen ?

  • vtkNRRDReader, vtkNRRDWriter classes were renamed to vtkTeemNRRDReader and vtkTeemNRRDWriter in r27102
  • Project impacted by the rename were all updated :+1:
  • but the update of the MultiVolumeExplorer hash was done after commit r27102 and the associated reference in Slicer/SuperBuild.cmake had NOT been updated as part of commit r27102 :-1:
  • To fix this, the MultiVolumeExplorer hash was updated in r27105 :+1:

Next time ?

  • Let’s make sure to update references of impacted Slicer Remote Module or any other external projects (files Slicer/SuperBuild/External_*.cmake) also impacted in the commit introducing the breaking change.

Dashboard ?

  • existing macOS and Windows entries were manually removed

  • For these reasons, the dashboard will not show anything in the “Update” column.

1 Like
2

Sorry about that. I’m not sure if it is possible with cmake, but would be nice if there was a way to ensure that out-of-tree code can’t break the build.

3

It is already possible to configure Slicer setting a hash of your choice for external project [1][2], would it help to have the same option for Slicer Remote ?

[1] ExternalProject_SetIfNotDefined
[2] and example of usage

4

I meant more along the lines of make -k (continue after failure excluding failed target dependees). We wouldn’t want to run the whole build like that, but it would be fine for remotes.

5

For users, a partially successful package would simply appear to be broken: some features are missing/not working). Missing parts of the core could cause various additional errors in extensions. I would rather not have a package with so many issues at all.