COMP: Harden vtkAddon version to use for custom builds - #34
Conversation
The IGSIO repo currently specifies the building of vtkAddon to use the "main" branch, so when SlicerIGSIO is built with IGSIO_USE_3DSlicer turned off, it began to fail due to recent updates to vtkAddon. When building SlicerIGSIO extension with an already built Slicer build with IGSIO_USE_3DSlicer set to ON, there wasn't an issue because 3D Slicer currently pins vtkAddon to a specific commit. This commit pins vtkAddon to a specific hash for custom builds or will use the passed vtkAddon revision specified to the configuration of SlicerIGSIO.
|
The changes look good to me, but I let @Sunderlandkyl to have a look at it, too. @jamesobutler please create an issue for the build error with latest vtkAddon and ping @AlexyPellegrini at Slicer/vtkAddon#67. They made the breaking changes, so they should help us updating the packages that depend on vtkAddon. |
|
Thanks @jamesobutler, the changes look good to me too. |
|
Note that the most common issue you may get since my change is related to the find_package(VTK) performed by vtkAddon that is now limited to required components to build vtkAddon, so you will have to perform your own find_package(VTK) if you need additional modules :) |
|
Here was the specific build error I observed when SlicerIGSIO is bundled into my custom app which builds IGSIO using IGSIO's superbuild (https://github.com/IGSIO/IGSIO/tree/master/SuperBuild) that was pulling vtkAddon |
|
Hi James, thank you for the error message. |
|
For reference my Slicer custom app (based on Slicer from October 2025, using VTK 9.5.2) was bundling the following items:
@AlexyPellegrini I have tested building my custom app again at these same SlicerIGSIO and IGSIO commits with it now using the latest vtkAddon (Slicer/vtkAddon@c8f8c6d) and it appears to still have issues. I'm observing IGSIO fail at: For my own app, I'll continue with the newly hardened vtkAddon option (96ec83b) so that I'm not relying on SlicerIGSIO/IGSIO to always be compatible with latest vtkAddon. I had recently tagged a stable release of my Slicer custom app which is when I realized I wasn't going to be able to build it successfully again when things broke with latest vtkAddon. I want to be able to build this stable release anytime in the future and I know latest vtkAddon isn't guaranteed to be compatible forever, so hardening it makes sense for my situation. |
|
Hi James, you now have the error I expected when I made the change, you have to find_package(VTK) in your project to have access to all VTK modules (preferably only the one you need), this will never be "fixed" in vtkAddon as it is how it should work. But I also think freezing dependencies is a good idea anyway, so both are good, just remember that if you ever bump vtkAddon, you will need your own find_package(VTK)! |
The IGSIO repo currently specifies the building of vtkAddon to use the "main" branch, so when SlicerIGSIO is built with IGSIO_USE_3DSlicer turned off, it began to fail due to recent updates to vtkAddon. When building SlicerIGSIO extension with an already built Slicer build with IGSIO_USE_3DSlicer set to ON, there wasn't an issue because 3D Slicer currently pins vtkAddon to a specific commit.
This commit pins vtkAddon to a specific hash for custom builds or will use the passed vtkAddon revision specified to the configuration of SlicerIGSIO.
cc: @Sunderlandkyl - it seems like you were having to do some recent compatibility fixes in IGSIO because of the recent vtkAddon integrated commits. I ran into issues with my 3D Slicer custom app which bundles SlicerIGSIO using a hardened commit and lists a hardened IGSIO commit to use, but IGSIO using its superbuild specified vtkAddon's
mainbranch (note that other IGSIO dependencies such as libwebm define a hardened hash instead of using a branch name, so it could be considered to have IGSIO define a hardened vtkAddon version instead of SlicerIGSIO). In this case of building SlicerIGSIO into a custom app,IGSIO_USE_3DSlicerdoesn't appear available to use as that seems to rely on a Slicer build tree as though building SlicerIGSIO as an extension against a Slicer build tree. Otherwise I would let the Slicer branch used by my custom app use its defined vtkAddon version and then have the building of IGSIO depend on that vtkAddon project and use that built version.With the passing of
vtkAddon_GIT_REVISIONdown into the IGSIO build, these changes will still need IGSIO/IGSIO#46 to avoid it getting set back tomain.Ultimately with these changes I could specify
vtkAddon_GIT_REVISIONin my Slicer custom build CMakeLists.txt andmark_as_superbuild(..)to then be consumed by SlicerIGSIO to then pass to IGSIO and its superbuild of vtkAddon.