COMP: Link the full Python library for wrapped modules where required

[pieper]

cc @AlexyPellegrini

Problem

This is the root cause of the current Linux build breakage in Slicer (Slicer/Slicer#9348), which appeared after the SuperBuild vtkAddon bump.

c44ce00 ("COMP: Only search for Python3 Development.Module component") did three coupled things:

1. switched find_package(Python3 COMPONENTS Development) → Development.Module,
2. removed set(VTK_WRAP_PYTHON_FIND_LIBS 1) in vtkMacroKitPythonWrap.cmake (so the "find the Python library" block in vtkWrapPython.cmake became dead and VTK_Python3_LIBRARIES is never set), and
3. removed ${VTK_Python3_LIBRARIES} from both target_link_libraries calls for the wrapped module.

Development.Module provides only Python3::Module, which deliberately leaves the Python C-API symbols undefined for the host interpreter to supply. That is fine where the linker allows undefined symbols (on macOS, MODULE targets link with -undefined dynamic_lookup), but on Linux the wrapped modules are linked with -Wl,--no-undefined (vtk_undefined_symbols_allowed=FALSE) and must resolve the Python symbols at link time. The result is a link failure of every wrapped module:

vtkAddonMathUtilitiesPython.cxx: undefined reference to `PyTuple_Size'

Fix

Restore what the removed code provided, gated on VTK_UNDEFINED_SYMBOLS_ALLOWED: keep Development.Module where undefined symbols are allowed, otherwise require the full Development component and link Python3::Python. VTK_WRAP_PYTHON_FIND_LIBS is set again so the block runs, and VTK_Python3_LIBRARIES is re-added to the wrapped-module link line (both the VTK<8.90 and VTK>=8.90 paths).

@AlexyPellegrini — since the Development.Module switch was intentional, flagging in case you'd prefer instead to exempt the wrapped MODULE targets from -Wl,--no-undefined (the way VTK's own module wrapper does). This PR takes the more conservative "restore the prior linkage" route to unbreak the dashboards.

Testing

Reproduced and fixed on an Ubuntu 22.04 Slicer superbuild (Release, VTK 9.6, Python 3.12): without the change the inner build fails linking the wrapped Python modules; with it, the full application builds, packages, and runs off the build machine — the previously-failing classes (vtkAddonMathUtilities, vtkSegmentation, …) load, and inherited base-class methods (vtkOrientedGridTransform.SetDisplacementGridData) are present.

🤖 Generated with Claude Code

[sjh26]

lgtm

[AlexyPellegrini]

When building Python modules on Linux and Mac it is intended to not link the python lib as the symbols are expected to be provided by running interpreter. This think this will break SlicerCore. Edit: or maybe not, if VTK_UNDEFINED_SYMBOLS_ALLOWED is defined that should be enough for SlicerCore.

To fix the original issue, JCFR indicated that we must add an option to tell VTK to not do this link by default: #27 (comment)

Once this option is defined, the VTK::Python target will have the appropriate flags to prevent link errors.

[pieper]

@AlexyPellegrini thanks for looking in to this. The current code works for both mac and linux for today's preview builds of Slicer so we don't want to regress. If you can suggest changes that work for your purposes and don't break Slicer that's good.

We discussed with @Thibault-Pelletier yesterday and people can stick to the earlier hash of vtkAddon if this new code is a problem for any projects.