I like very much the idea of having vtkAddon as a separated project as introduced in aaf75e2aaa. In this logic, one can think about vtkAddon being a dependency of Slicer --this helps e.g., supporting the idea of having 3D Slicer installed in a system alongside other related projects, where the common dependencies are shared.
In the current implementation, the python wrapping of vtkAddon relies on macros defined in vtkMacroKitPythonWrap.cmake (which is part of 3D Slicer), making impossible to build vtkAddon by itself and producing a cyclic dependency vtkAddon–>Slicer–>vtkAddon.
I would suggest to move a copy of vtkMacroKitPythonWrap.cmake to vtkAddon/CMake as a temporary solution, assuming that the integration of the official VTK will soon come, and that VTK will be the provider of the wrapping functions. Does it make sense? Any thoughts?
I see that the Slicer fork of vtkAddon is much more tangled to Slicer than I thought; there are also some specific Slicer variables.
Would it make sense to make like a neutral vtkAddon with all the additions over the original by Lorensen (python wrapping, extra components)? Slicer could get the same configuration by passing cmake variables to the external project and let other projects use it.
We will revisit the approach when transitioning to use the latest version of VTK (in the coming days), and will most likely get ride of vtkMacroKitPythonWrap.cmake and use the latest build-system infrastructure made available in VTK.