SlicerElastix extension not available on Mac

registration
build
extensions

(Csaba Pinter) #1

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


Elastix extension for Mac OSX not available
Slicer elastix on Mac
General Registration Elastix extension Mac
(Csaba Pinter) #2

@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!


(Andras Lasso) #3

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?


(Kyle Sunderland) #4

@lassoan Compiles fine using the most recent Elastix version in the master branch (once some paths are changed in elastix_patch.cmake).


(Andras Lasso) #5

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!


(Csaba Pinter) #6

Or we could use the master instead of a hash.


(Jean Christophe Fillion Robin) #7

Nice work finding out the source of the problem :+1:

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.


(Csaba Pinter) #8

Not sure I agree.

  • Fixed hash: You build the custom app on day 1, with extension hash A. Then you build custom app on day 2 with extension hash B. There is a bug related to extension. You need to go to the extension index and see which hash was used on day 1 and 2, and compare the two hashes
  • Master: You build the custom app on day 1, with extension hash A. Then you build custom app on day 2 with extension hash B. There is a bug related to extension. You need to go to the extension repository and see what was the head each time. Compare the two hashes.

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.


(Kyle Sunderland) #9

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.


(Andrey Fedorov) #10

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.


(Csaba Pinter) #11

I was talking about the ExtensionIndex, not the Elastix external in the superbuild extension. So I agree with this.


(Andrey Fedorov) #12

Sorry for my confusion!

ps I thought @jcfr was talking about actual hash for elastix, not SlicerElastix.


(Csaba Pinter) #13

Probably he did and I was the one who misunderstood :slight_smile:

We also use fixed hash for superbuild extension dependencies, and I agree with @jcfr’s concerns about that.


(Andras Lasso) #14

I’ve updated SlicerElastix to use a specific Elastix hash.


Slicer elatix cannot be installed
(Csaba Pinter) #18

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.


(Andras Lasso) #19

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.


(Csaba Pinter) #20

For the record, Mac build of SlicerElastix is available as of February 13.