Interpreting CDash reporting: extension is packaged despite build errors?

I checked the dashboard today, and I found that one of our extension had a (new) build error:

Error copying file "@rpath/libITKFactoryRegistration.dylib" to 

However, despite of this error, the extension package is available, and it seems to work in Slicer.

@jcfr could this potentially be related to the fixes discussed in No nightly Mac binary since August 1?

Look like a legitimate error associated with packaging. I will have a look.

To clarify, packaging is technically not part of the “build”, it happens afterward.

That said, we drive the packaging using ctest_build and submit the additional results like they were a build output. That is packaging error are reported like “build” errors.

Thanks for looking into this @jcfr!

Note that there were no changes to the extension source code between the latest successful build/package (Aug 1, and the date when failure was first observed (Aug 9, In between there were no Mac builds of extensions at all. So it looks like the problem is on the Slicer side.

@jcfr the problem I mentioned above persists:

I see the same problem for a large number of other C++ extensions. Is there a plan to address this regression in the Slicer core?

One of the MacOSX issue is now addressed by r26296, I will follow up on the dcmqi error tomorrow.

1 Like

macOS packaging issue will be addressed by

1 Like

Thank you @jcfr for tracking this down!

I am sure you will let us know if any updates will be needed for the extensions!

This should be fixed in r26301

And here is a follow up commit addressing the remaining issues in Slicer. See r26305

Corresponding changes in upstream projects are here: