Hi all,
I wanted to show a Mac user the SlicerElastix extension but it was not there. After a bit of investigation, it turns out that it does not build at least since February.
Here’s the latest dashboard and the error (and the oldest available dashboard).
Does anyone know what is needed in order to fix this? Can someone who usually develops on Mac check it out? Elastix is a great registration tool, we should have it in 4.10.
Thanks,
csaba
@Sunderlandkyl managed to compile it locally. There were tons of warnings but no errors.
@jcfr It seems on the dashboard that the same thing happened as for Kyle, but the warnings are somehow treated as errors. Maybe fixing the wrong parsing of the log would solve the problem?
Thanks!
I think build log parsing is only used for categorizing messages for dashboard display and does not have an effect on the build process (build error is detected by getting non-zero exit value of compiler and linker process).
@Sunderlandkyl could you try to build with latest Elastix version?
@lassoan Compiles fine using the most recent Elastix version in the master branch (once some paths are changed in elastix_patch.cmake).
Great! Could you please send a pull request with the necessary changes and the git hash you have tested with? Maybe build will succeed with this new version. Thank you!
Or we could use the master instead of a hash.
Nice work finding out the source of the problem 
That said, I recommend against using the master branch in the actual extension code. This will make integration in custom application difficult as checking the code on day1 and on day2 could lead to different behavior and could make the reproduction of results very challenging, and the tracking of error difficult.
Not sure I agree.
To me the two workflows seem to take the same amount of effort, except if there were many commits on day 1 in the second case, but le’s face it it’s very unlikely.
On the other hand when you change anything in an extension that you want to make its way into the release you need to update the hash every single time in extension index, which is significant overhead, not mentioning the fact that it’s easy to forget about.
The build is still failing in the same way as before, so changing the elastix version did not seem to have an effect: http://slicer.cdash.org/viewBuildError.php?buildid=1425226.
I don’t think this will be easy, and sometime it may not be possible. If you have SlicerElastix that depends on elastix “master” branch, it might be challenging to figure out which exact hash was checked out based on the specific time of the build. Imagine the scenario when prolific elastix developers make several commits on the night (morning in Europe) when Slicer dashboards checks out SlicerElastix.
+1 for FixedHash of the elastix repo and “master” for SlicerElastix in SlicerElastix.s4ext.
I was talking about the ExtensionIndex, not the Elastix external in the superbuild extension. So I agree with this.
Sorry for my confusion!
ps I thought @jcfr was talking about actual hash for elastix, not SlicerElastix.
Probably he did and I was the one who misunderstood 
We also use fixed hash for superbuild extension dependencies, and I agree with @jcfr’s concerns about that.
The build still fails. The errors still look like warnings, most of them (all of the ones I read) the type "overrides a member function but is not marked ‘override’ ".
It still seems to me that the problem is only with parsing the output, given that @Sunderlandkyl built it successfully.
@jcfr could you take a look at this dashboard entry please? You’ll probably see the problem immediately.
Log parser in CTest may misinterpret messages, but this does not affect the build process. Only return value of compiler, linker, etc. process execution matters. The easiest would be to restart the build on the factory machine. Then most likely the warnings would not be displayed again and you would immediately see the actual build error message.
For the record, Mac build of SlicerElastix is available as of February 13.