Skip to content

COMP: Harden vtkAddon version to use for custom builds - #34

Merged
Sunderlandkyl merged 1 commit into
IGSIO:masterfrom
jamesobutler:vtkaddon-hardening-for-custom-apps
Apr 17, 2026
Merged

COMP: Harden vtkAddon version to use for custom builds#34
Sunderlandkyl merged 1 commit into
IGSIO:masterfrom
jamesobutler:vtkaddon-hardening-for-custom-apps

Conversation

@jamesobutler

@jamesobutler jamesobutler commented Apr 16, 2026

Copy link
Copy Markdown
Contributor

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 main branch (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_3DSlicer doesn'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_REVISION down into the IGSIO build, these changes will still need IGSIO/IGSIO#46 to avoid it getting set back to main.

Ultimately with these changes I could specify vtkAddon_GIT_REVISION in my Slicer custom build CMakeLists.txt and mark_as_superbuild(..) to then be consumed by SlicerIGSIO to then pass to IGSIO and its superbuild of vtkAddon.

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.
@lassoan

lassoan commented Apr 17, 2026

Copy link
Copy Markdown
Contributor

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.

@Sunderlandkyl
Sunderlandkyl merged commit 96ec83b into IGSIO:master Apr 17, 2026
@Sunderlandkyl

Copy link
Copy Markdown
Collaborator

Thanks @jamesobutler, the changes look good to me too.

@jamesobutler
jamesobutler deleted the vtkaddon-hardening-for-custom-apps branch April 17, 2026 15:29
@AlexyPellegrini

Copy link
Copy Markdown

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 :)

@jamesobutler

jamesobutler commented Apr 17, 2026

Copy link
Copy Markdown
Contributor Author

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 main (Slicer/vtkAddon@7b6a2fd).

48>  CMake Error at C:/MyCustomApp/IGSIO-build/vtkAddon-bin/vtkAddonConfig.cmake:1 (include):
48>    include could not find requested file:
48>
48>      C:/MyCustomApp/IGSIO-build/inner-build/Codecs/vtkAddonTargets.cmake
48>  Call Stack (most recent call first):
48>    Codecs/CMakeLists.txt:6 (find_package)
48>
48>
48>  CMake Error at C:/MyCustomApp/IGSIO-build/vtkAddon-bin/vtkAddonConfig.cmake:1 (include):
48>    include could not find requested file:
48>
48>      C:/MyCustomApp/IGSIO-build/inner-build/IGSIOCommon/vtkAddonTargets.cmake
48>  Call Stack (most recent call first):
48>    IGSIOCommon/CMakeLists.txt:6 (find_package)

@AlexyPellegrini

Copy link
Copy Markdown

Hi James, thank you for the error message.
Can you try with that branch https://github.com/AlexyPellegrini/vtkAddon/tree/fix-build-tree-config?

@jamesobutler

jamesobutler commented Apr 21, 2026

Copy link
Copy Markdown
Contributor Author

For reference my Slicer custom app (based on Slicer from October 2025, using VTK 9.5.2) was bundling the following items:

  • SlicerIGSIO as of 1a89776
  • IGSIO as of IGSIO/IGSIO@af00824
  • vtkAddon (main) by default as of the IGSIO commit with configuration to build its superbuild
#-----------------------------------------------------------------------------
# SlicerIGSIO
set(extension_name "SlicerIGSIO")
set(${extension_name}_SOURCE_DIR "${CMAKE_BINARY_DIR}/${extension_name}")
ExternalProject_SetIfNotDefined(
  ${CMAKE_PROJECT_NAME}_IGSIO_GIT_TAG
  "af00824506c7c099a37daa180a7af191d0d274a1"
  QUIET
  )
FetchContent_Populate(${extension_name}
 SOURCE_DIR     ${${extension_name}_SOURCE_DIR}
 GIT_REPOSITORY ${EP_GIT_PROTOCOL}://github.com/IGSIO/${extension_name}.git
 GIT_TAG        1a89776c9f1c8bbbad62000561aa892afe1e7077
 GIT_PROGRESS   1
 QUIET
 )
list(APPEND Slicer_EXTENSION_SOURCE_DIRS ${${extension_name}_SOURCE_DIR})
ExternalProject_Add_Dependencies(IGSIO
  DEPENDS
    ITK
    VTK
    VP9
    YASM
  )
ExternalProject_Add_Dependencies(YASM
  DEPENDS
    python
  )

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

48>    vtkIGSIOSequenceIOBase.cxx
48>C:\LisaApp3\IGSIO\SequenceIO\vtkIGSIOMetaImageSequenceIO.h(17,10): error C1083: Cannot open include file: 'vtk_zlib.h': No such file or directory [C:\LisaApp3\IGSIO-build\inner-build\SequenceIO\vtkSequenceIO.vcxproj] [C:\LisaApp3\IGSIO-build\inner-build.vcxproj]
48>    (compiling source file '../../../IGSIO/SequenceIO/vtkIGSIOSequenceIO.cxx')
48>
48>    vtkIGSIOMetaImageSequenceIO.cxx
48>C:\LisaApp3\IGSIO\SequenceIO\vtkIGSIOMetaImageSequenceIO.h(17,10): error C1083: Cannot open include file: 'vtk_zlib.h': No such file or directory [C:\LisaApp3\IGSIO-build\inner-build\SequenceIO\vtkSequenceIO.vcxproj] [C:\LisaApp3\IGSIO-build\inner-build.vcxproj]
48>    (compiling source file '../../../IGSIO/SequenceIO/vtkIGSIOMetaImageSequenceIO.cxx')
48>
48>    vtkIGSIONrrdSequenceIO.cxx
48>C:\LisaApp3\IGSIO\SequenceIO\vtkIGSIONrrdSequenceIO.h(17,10): error C1083: Cannot open include file: 'vtk_zlib.h': No such file or directory [C:\LisaApp3\IGSIO-build\inner-build\SequenceIO\vtkSequenceIO.vcxproj] [C:\LisaApp3\IGSIO-build\inner-build.vcxproj]
48>    (compiling source file '../../../IGSIO/SequenceIO/vtkIGSIONrrdSequenceIO.cxx')')

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.

@AlexyPellegrini

Copy link
Copy Markdown

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants