Hi all,
My clean Slicer builds failed, with undeterministic errors about CTK and/or ITK configuration.
I checked and the dashboard shows failed build on all platforms
http://slicer.cdash.org/index.php?project=SlicerPreview
Since I didn’t see any other possible cause, I reverted https://github.com/Slicer/Slicer/commit/aa6083015618f425653203df0eae90a4f9df7492
and tried again. It has not failed yet but did not get too far either.
Please take a look at this.
Thanks!
@jcfr I don’t think you ever pushed the new branch for Slicer/ITK as part of this recent commit https://github.com/Slicer/Slicer/commit/aa6083015618f425653203df0eae90a4f9df7492
.
Yep, the ITK on the Slicer fork branch that Slicer master wants to reference is missing. Pushing that branch will fix.
Thanks for checking!
So it seems no changes are needed in Slicer itself.
Interesting that my windows build errors were not definite… The mac and linux dashboards are much more informative.
… They are all giving the exact same error when I look at CDash?
From the windows build: CDash
fatal: reference is not a tree: 35e6f546438557f22e66db25e066499637890214
CMake Error at ITK-prefix/tmp/ITK-gitclone.cmake:40 (message):
Failed to checkout tag: ‘35e6f546438557f22e66db25e066499637890214’
Right. My local build gave me generic “cmd” errors, sometimes when configuring ITK sometimes when CTK. Not sure why.
So the non-specific cmd error are to be expected, since cmake/VS uses cmd.exe to execute system functions (git, file copies, etc.). To figure out what actually happened, I usually search for CMake Error in the build output.
Visual Studio isn’t great with its reporting of these build target errors, and sometimes they get attached to the wrong project.
Anyway, If we get that branch issues fixed in the next few hours, I will re-trigger the nightly builds.
Ooops. Good catch. This should now be fixed.
Great!
Should we retrigger the nightly? My concern is that the extension builds will not finish before the next nightly is scheduled (esp. for windows). If we skip the extensions, then the current nightly download wont have a working extension manager until next morning. I am thinking we just skip for today, so that yesterday’s build will remain on the download page, unless it is critical to see build status today.
I updated and started a build. I’m getting errors like
c:\d\s4r\itk\modules\core\common\include\itkThreadSupport.h(59): error C2065: 'ITK_DEFAULT_MAX_THREADS': undeclared identifier [C:\d\S4R\Slicer-build
\Modules\Loadable\Markups\Logic\vtkSlicerMarkupsModuleLogicPythonD.vcxproj] [C:\d\S4R\Slicer.vcxproj]
c:\d\s4r\itk\modules\core\common\include\itkThreadSupport.h(59): error C2131: expression did not evaluate to a constant [C:\d\S4R\Slicer-build\Module
s\Loadable\Markups\Logic\vtkSlicerMarkupsModuleLogicPythonD.vcxproj] [C:\d\S4R\Slicer.vcxproj]
Something is still going on.
Can you locate itkConfigure.h in your itk build, and check what it has (if anything) for ITK_DEFAULT_MAX_THREADS? We may need to update the External_ITK file,
Sorry I reverted again. I’d need to work but have been struggling with this all day so far.
That’s fine, I am going to start a local build to look at this.
Just checked the result of my builds at work, and there is (hopefully) one last issue:
c:\d\s4r\brainstools\brainscommonlib\genericRegistrationHelper.h(506): error C2555: 'itk::MultiModal3DMutualRegistrationHelper<TransformType,Optimi
zerType,FixedImageType,MovingImageType,FitCommonCodeMetricType>::GetMTime': overriding virtual function return type differs and is not covariant from
'itk::Object::GetMTime' [C:\d\S4R\Slicer-build\E\BRAINSTools\BRAINSCommonLib\BRAINSCommonLib.vcxproj] [C:\d\S4R\Slicer.vcxproj]
c:\d\slicer\modules\cli\expertautomatedregistration\itkregistrationhelper\itkImageToImageRegistrationMethod.h(147): error C2555: 'itk::ImageToImage
RegistrationMethod<TImage>::GetMTime': overriding virtual function return type differs and is not covariant from 'itk::Object::GetMTime' [C:\d\S4R\Sl
icer-build\Modules\CLI\ExpertAutomatedRegistration\ExpertAutomatedRegistrationLib.vcxproj] [C:\d\S4R\Slicer.vcxproj]
c:\d\slicer\modules\cli\resampledtivolume\itkDiffusionTensor3DResample.h(78): error C2555: 'itk::DiffusionTensor3DResample<PixelType,PixelType>::Ge
tMTime': overriding virtual function return type differs and is not covariant from 'itk::Object::GetMTime' [C:\d\S4R\Slicer-build\Modules\CLI\Resampl
eDTIVolume\ResampleDTIVolumeLib.vcxproj] [C:\d\S4R\Slicer.vcxproj]
c:\d\slicer\modules\cli\resampledtivolume\itkTransformDeformationFieldFilter.h(58): error C2555: 'itk::TransformDeformationFieldFilter<double,doubl
e,3>::GetMTime': overriding virtual function return type differs and is not covariant from 'itk::Object::GetMTime' [C:\d\S4R\Slicer-build\Modules\CLI
\ResampleDTIVolume\ResampleDTIVolumeLib.vcxproj] [C:\d\S4R\Slicer.vcxproj]
c:\d\slicer\modules\cli\resampledtivolume\itkDiffusionTensor3DResample.h(78): error C2555: 'itk::DiffusionTensor3DResample<PixelType,PixelType>::Ge
tMTime': overriding virtual function return type differs and is not covariant from 'itk::Object::GetMTime' [C:\d\S4R\Slicer-build\Modules\CLI\Resampl
eDTIVolume\ResampleDTIVolumeLib.vcxproj] [C:\d\S4R\Slicer.vcxproj]
c:\d\slicer\modules\cli\resampledtivolume\itkTransformDeformationFieldFilter.h(58): error C2555: 'itk::TransformDeformationFieldFilter<double,doubl
e,3>::GetMTime': overriding virtual function return type differs and is not covariant from 'itk::Object::GetMTime' [C:\d\S4R\Slicer-build\Modules\CLI
\ResampleScalarVectorDWIVolume\ResampleScalarVectorDWIVolumeLib.vcxproj] [C:\d\S4R\Slicer.vcxproj]
The dashboard shows this too, and apparently only Windows is affected. Builds on the other two platforms are fine.
I see this, too. I’m just testing if replacing unsigned long by ModifiedTimeType fixes the issue.
I’ve pushed a fix in Slicer.
Unfortunately, there is a single use of the old unsigned long type in BRAINS, too (BRAINSTools\BRAINSCommonLib\genericRegistrationHelper.hxx and .h).
@jcfr or @Sam_Horvath could you take care of this?
Sure, I can get that.