-
Notifications
You must be signed in to change notification settings - Fork 503
Add files via upload #930
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Add files via upload #930
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Temporary solution for MS Visual Studio 2019 with PluginFramework.
Add description of required CMake variables.
I am linking this pull request with this new issue I made : #933 |
jcfr
added a commit
to jcfr/Slicer
that referenced
this pull request
Sep 30, 2020
This commit enables support for building Slicer against VTK 8.2.0 or 9.0.0 by setting the option Slicer_VTK_VERSION_MAJOR. By default, VTK 9 is used. Notes: * VTK_USE_FILE is included only if VTK <= 8.90. * To support building against both version of VTK and use the relevant names for targets and components, variables VTK_TARGET_PREFIX and VTK_COMPONENT_PREFIX have been introduced. * vtkArchive: Change call from "GetCurrentWorkingDirectory(true)" to "GetCurrentWorkingDirectory()", since the default parameter value was "true", it does not change the behavior. Change originally introduced in Kitware/VTK@d33a5e5e6 * Disable verbosity associated with vtkLogger to ensure all messages are captured by the existing logging infrastructure. * Update VTK removing FindTBB and expect VTK to be configured with TBB_DIR. Alternative approach where passing CMake variables satisfying both ITK and VTK have been considered but we would have required to update every project doing a "find_package(ITK)" because "ITKVTKGlue" only configure the value TBB_DIR in the generated module files. For reference, error encountered where like the following: CMake Error at D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:116 (message): Required library TBB not found. Call Stack (most recent call first): D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:352 (findpkg_finish) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:538 (find_package) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/vtk-config.cmake:138 (include) D:/T/S-b/VTK-build/vtk-config.cmake:1 (include) Modules/Bridge/VtkGlue/itk-module-init.cmake:9 (find_package) CMake/ITKModuleEnablement.cmake:321 (include) CMakeLists.txt:478 (include) CTK configuration error: CMake Error at D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:116 (message): Required library TBB not found. Call Stack (most recent call first): D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:352 (findpkg_finish) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:538 (find_package) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/vtk-config.cmake:138 (include) D:/T/S-b/VTK-build/vtk-config.cmake:1 (include) D:/T/S-b/ITK-build/lib/cmake/ITK-5.1/Modules/ITKVtkGlue.cmake:30 (find_package) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:76 (include) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:31 (itk_module_load) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:129 (_itk_module_config_recurse) D:/T/S-b/ITK-build/ITKConfig.cmake:77 (itk_module_config) CMakeLists.txt:1004 (find_package) * Fix packaging of VTK 9 components on windows and linux specifying expected component names to install: "runtime" and "python" if slicer is built with python support. * Update wrapping infrastructure to support VTK >= 8.90: - Support wrapping of VTK based classes independently of the version of VTK being used, a custom copy of vtkWrapHierarchy, vtkWrapPython and vtkWrapperInit.data.in have been added. - With VTK >= 8.90, merge Python with PythonD libraries - Update vtkWrapPython to make sure remote modules targets are ignored when wrapping Slicer classes. - Update VTK wrapping CMake modules to ensure hierarchy files of dependencies are passed to both vtkWrapHierarchy and vtkWrapPython tools using the --types parameter. See See https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100 VTK has also been updated to disable the relative import generated in the "*InitImpl.cxx" files. It led to the generation of code similar to the following which was failing when trying to perform the relative import of Slicer wrapped modules using "vtkPythonUtil::ImportModule": const char *depends[4] = { "vtkAddonPython", "vtkITKPython", "vtkSegmentationCorePython", "vtkTeemPython", }; for (int i = 0; i < 4; i++) { if (!vtkPythonUtil::ImportModule(depends[i], d)) { return PyErr_Format(PyExc_ImportError, "Failed to load MRMLCorePython: No module named %s", depends[i]); } } - Fix slicer.util.importModuleObjects to work with VTK >- 8.90 Since python module generated using VTK>=8.90 already take care of importing their dependencies using `vtkPythonUtil::ImportModule`, the sys.modules dict is updated early on. To accomodate this, this commit changes the test checking if items of an object have already been imported into the target one. - Fix wrapping of module logic Explicitly list transitive VTK dependencies because _get_dependencies_recurse used in vtkAddon/CMake/vtkMacroKitPythonWrap.cmake does not recurse over dependencies that are VTK python wrapped. 10000 Before: >>> slicer.modules.cameras.logic() (SlicerBaseLogic.vtkSlicerModuleLogic)0x7fe68dea2588 After: >>> slicer.modules.cameras.logic() (vtkSlicerCamerasModuleLogic.vtkSlicerCamerasModuleLogic)0x7fbed69c42e8 * To avoid configuration warning and link errors like the following, it is important to publish relevant tag onto the Slicer/VTK fork. Simply commenting the call to "determine_version" was not the correct approach. CMake Warning at CMake/VTKDetermineVersion.cmake:64 (message): Version from git (7.0.0) disagrees with hard coded version (9.0.20200825). Either update the git tags or version.txt. macOS link error: ld: malformed 64-bit a.b.c.d.e version number: 9.0.20200825 clang: error: linker command failed with exit code 1 (use -v to see invocation) --------------------------------------------- List of VTK changes integrated on top of Slicer/VTK@3fa220f28e5: $ git shortlog 3fa220f..2f4e011bfc --no-merges Davide Punzo (1): [backport MR-7193] ENH: add double click events Jean-Christophe Fillion-Robin (3): COMP: Remove vtk-m submodule COMP: Remove FindTBB and expect VTK to be configured with TBB_DIR BUG: Update vtkPythonUtil to disable relative import causing crash for Slicer modules --------------------------------------------- List of CTK changes: $ git shortlog 92d2191b..48e4a3f3 --no-merges Andras Lasso (1): COMP: Fix build error in ctkLDAPExpr.cpp Jean-Christophe Fillion-Robin (3): COMP: Fix build of ctkVTKWidgetsUtilsTestImageConversion using Qt 5.10 COMP: Remove support for building against VTK <= 5.8 COMP: Add support for building against VTK >= 8.90 al-sabr (1): Add files via upload (commontk/CTK#930) --------------------------------------------- List of vtkAddon changes: $ git shortlog a64d854..5df87de --no-merges Jean-Christophe Fillion-Robin (1): ENH: Add support for building against VTK >= 8.90 --------------------------------------------- List of SurfaceToolbox changes: $ git shortlog 28b2567..501a0c7 --no-merges Jean-Christophe Fillion-Robin (1): COMP: Fix wrapping of vtkSlicerDynamicModeler classes with VTK >= 8.90 Co-authored-by: Andras Lasso <lasso@queensu.ca> Co-authored-by: Csaba Pinter <pinter.csaba@gmail.com> Co-authored-by: David Gobbi <david.gobbi@gmail.com> Co-authored-by: Davide Punzo <punzodavide@hotmail.it> Co-authored-by: Jean-Christophe Fillion-Robin <jchris.fillionr@kitware.com>
jcfr
added a commit
to jcfr/Slicer
that referenced
this pull request
Sep 30, 2020
This commit enables support for building Slicer against VTK 8.2.0 or 9.0.0 by setting the option Slicer_VTK_VERSION_MAJOR. By default, Slicer_VTK_VERSION_MAJOR is set to 8 Notes: * VTK_USE_FILE is included only if VTK <= 8.90. * To support building against both version of VTK and use the relevant names for targets and components, variables VTK_TARGET_PREFIX and VTK_COMPONENT_PREFIX have been introduced. * vtkArchive: Change call from "GetCurrentWorkingDirectory(true)" to "GetCurrentWorkingDirectory()", since the default parameter value was "true", it does not change the behavior. Change originally introduced in Kitware/VTK@d33a5e5e6 * Disable verbosity associated with vtkLogger to ensure all messages are captured by the existing logging infrastructure. * Update VTK removing FindTBB and expect VTK to be configured with TBB_DIR. Alternative approach where passing CMake variables satisfying both ITK and VTK have been considered but we would have required to update every project doing a "find_package(ITK)" because "ITKVTKGlue" only configure the value TBB_DIR in the generated module files. For reference, error encountered where like the following: CMake Error at D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:116 (message): Required library TBB not found. Call Stack (most recent call first): D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:352 (findpkg_finish) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:538 (find_package) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/vtk-config.cmake:138 (include) D:/T/S-b/VTK-build/vtk-config.cmake:1 (include) Modules/Bridge/VtkGlue/itk-module-init.cmake:9 (find_package) CMake/ITKModuleEnablement.cmake:321 (include) CMakeLists.txt:478 (include) CTK configuration error: CMake Error at D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:116 (message): Required library TBB not found. Call Stack (most recent call first): D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:352 (findpkg_finish) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:538 (find_package) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/vtk-config.cmake:138 (include) D:/T/S-b/VTK-build/vtk-config.cmake:1 (include) D:/T/S-b/ITK-build/lib/cmake/ITK-5.1/Modules/ITKVtkGlue.cmake:30 (find_package) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:76 (include) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:31 (itk_module_load) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:129 (_itk_module_config_recurse) D:/T/S-b/ITK-build/ITKConfig.cmake:77 (itk_module_config) CMakeLists.txt:1004 (find_package) * Fix packaging of VTK 9 components on windows and linux specifying expected component names to install: "runtime" and "python" if slicer is built with python support. * Update wrapping infrastructure to support VTK >= 8.90: - Support wrapping of VTK based classes independently of the version of VTK being used, a custom copy of vtkWrapHierarchy, vtkWrapPython and vtkWrapperInit.data.in have been added. - With VTK >= 8.90, merge Python with PythonD libraries - Update vtkWrapPython to make sure remote modules targets are ignored when wrapping Slicer classes. - Update VTK wrapping CMake modules to ensure hierarchy files of dependencies are passed to both vtkWrapHierarchy and vtkWrapPython tools using the --types parameter. See See https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100 VTK has also been updated to disable the relative import generated in the "*InitImpl.cxx" files. It led to the generation of code similar to the following which was failing when trying to perform the relative import of Slicer wrapped modules using "vtkPythonUtil::ImportModule": const char *depends[4] = { "vtkAddonPython", "vtkITKPython", "vtkSegmentationCorePython", "vtkTeemPython", }; for (int i = 0; i < 4; i++) { if (!vtkPythonUtil::ImportModule(depends[i], d)) { return PyErr_Format(PyExc_ImportError, "Failed to load MRMLCorePython: No module named %s", depends[i]); } } - Fix slicer.util.importModuleObjects to work with VTK >- 8.90 Since python module generated using VTK>=8.90 already take care of importing their dependencies using `vtkPythonUtil::ImportModule`, the sys.modules dict is updated early on. To accomodate this, this commit changes the test checking if items of an object have already been imported into the target one. - Fix wrapping of module logic Explicitly list transitive VTK dependencies because _get_dependencies_recurse used in vtkAddon/CMake/vtkMacroKitPythonWrap.cmake does not recurse over dependencies that are VTK python wrapped. Before: >>> slicer.modules.cameras.logic() (SlicerBaseLogic.vtkSlicerModuleLogic)0x7fe68dea2588 After: >>> slicer.modules.cameras.logic() (vtkSlicerCamerasModuleLogic.vtkSlicerCamerasModuleLogic)0x7fbed69c42e8 * To avoid configuration warning and link errors like the following, it is important to publish relevant tag onto the Slicer/VTK fork. Simply commenting the call to "determine_version" was not the correct approach. CMake Warning at CMake/VTKDetermineVersion.cmake:64 (message): Version from git (7.0.0) disagrees with hard coded version (9.0.20200825). Either update the git tags or version.txt. macOS link error: ld: malformed 64-bit a.b.c.d.e version number: 9.0.20200825 clang: error: linker command failed with exit code 1 (use -v to see invocation) --------------------------------------------- List of VTK changes integrated on top of Slicer/VTK@3fa220f28e5: $ git shortlog 3fa220f..2f4e011bfc --no-merges Davide Punzo (1): [backport MR-7193] ENH: add double click events Jean-Christophe Fillion-Robin (3): COMP: Remove vtk-m submodule COMP: Remove FindTBB and expect VTK to be configured with TBB_DIR BUG: Update vtkPythonUtil to disable relative import causing crash for Slicer modules --------------------------------------------- List of CTK changes: $ git shortlog 92d2191b..48e4a3f3 --no-merges Andras Lasso (1): COMP: Fix build error in ctkLDAPExpr.cpp Jean-Christophe Fillion-Robin (3): COMP: Fix build of ctkVTKWidgetsUtilsTestImageConversion using Qt 5.10 COMP: Remove support for building against VTK <= 5.8 COMP: Add support for building against VTK >= 8.90 al-sabr (1): Add files via upload (commontk/CTK#930) --------------------------------------------- List of vtkAddon changes: $ git shortlog a64d854..5df87de --no-merges Jean-Christophe Fillion-Robin (1): ENH: Add support for building against VTK >= 8.90 --------------------------------------------- List of SurfaceToolbox changes: $ git shortlog 28b2567..501a0c7 --no-merges Jean-Christophe Fillion-Robin (1): COMP: Fix wrapping of vtkSlicerDynamicModeler classes with VTK >= 8.90 Co-authored-by: Andras Lasso <lasso@queensu.ca> Co-authored-by: Csaba Pinter <pinter.csaba@gmail.com> Co-authored-by: David Gobbi <david.gobbi@gmail.com> Co-authored-by: Davide Punzo <punzodavide@hotmail.it> Co-authored-by: Jean-Christophe Fillion-Robin <jchris.fillionr@kitware.com>
jcfr
added a commit
to jcfr/Slicer
that referenced
this pull request
Sep 30, 2020
This commit enables support for building Slicer against VTK 8.2.0 or 9.0.0 by setting the option Slicer_VTK_VERSION_MAJOR. By default, Slicer_VTK_VERSION_MAJOR is set to 8 Notes: * VTK_USE_FILE is included only if VTK <= 8.90. * To support building against both version of VTK and use the relevant names for targets and components, variables VTK_TARGET_PREFIX and VTK_COMPONENT_PREFIX have been introduced. * vtkArchive: Change call from "GetCurrentWorkingDirectory(true)" to "GetCurrentWorkingDirectory()", since the default parameter value was "true", it does not change the behavior. Change originally introduced in Kitware/VTK@d33a5e5e6 * Disable verbosity associated with vtkLogger to ensure all messages are captured by the existing logging infrastructure. * Update VTK removing FindTBB and expect VTK to be configured with TBB_DIR. Alternative approach where passing CMake variables satisfying both ITK and VTK have been considered but we would have required to update every project doing a "find_package(ITK)" because "ITKVTKGlue" only configure the value TBB_DIR in the generated module files. For reference, error encountered where like the following: CMake Error at D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:116 (message): Required library TBB not found. Call Stack (most recent call first): D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:352 (findpkg_finish) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:538 (find_package) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/vtk-config.cmake:138 (include) D:/T/S-b/VTK-build/vtk-config.cmake:1 (include) Modules/Bridge/VtkGlue/itk-module-init.cmake:9 (find_package) CMake/ITKModuleEnablement.cmake:321 (include) CMakeLists.txt:478 (include) CTK configuration error: CMake Error at D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:116 (message): Required library TBB not found. Call Stack (most recent call first): D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:352 (findpkg_finish) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:538 (find_package) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/vtk-config.cmake:138 (include) D:/T/S-b/VTK-build/vtk-config.cmake:1 (include) D:/T/S-b/ITK-build/lib/cmake/ITK-5.1/Modules/ITKVtkGlue.cmake:30 (find_package) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:76 (include) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:31 (itk_module_load) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:129 (_itk_module_config_recurse) D:/T/S-b/ITK-build/ITKConfig.cmake:77 (itk_module_config) CMakeLists.txt:1004 (find_package) * Fix packaging of VTK 9 components on windows and linux specifying expected component names to install: "runtime" and "python" if slicer is built with python support. * Update wrapping infrastructure to support VTK >= 8.90: - Support wrapping of VTK based classes independently of the version of VTK being used, a custom copy of vtkWrapHierarchy, vtkWrapPython and vtkWrapperInit.data.in have been added. - With VTK >= 8.90, merge Python with PythonD libraries - Update vtkWrapPython to make sure remote modules targets are ignored when wrapping Slicer classes. - Update VTK wrapping CMake modules to ensure hierarchy files of dependencies are passed to both vtkWrapHierarchy and vtkWrapPython tools using the --types parameter. See See https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100 VTK has also been updated to disable the relative import generated in the "*InitImpl.cxx" files. It led to the generation of code similar to the following which was failing when trying to perform the relative import of Slicer wrapped modules using "vtkPythonUtil::ImportModule": const char *depends[4] = { "vtkAddonPython", "vtkITKPython", "vtkSegmentationCorePython", "vtkTeemPython", }; for (int i = 0; i < 4; i++) { if (!vtkPythonUtil::ImportModule(depends[i], d)) { return PyErr_Format(PyExc_ImportError, "Failed to load MRMLCorePython: No module named %s", depends[i]); } } - Fix slicer.util.importModuleObjects to work with VTK >- 8.90 Since python module generated using VTK>=8.90 already take care of importing their dependencies using `vtkPythonUtil::ImportModule`, the sys.modules dict is updated early on. To accomodate this, this commit changes the test checking if items of an object have already been imported into the target one. - Fix wrapping of module logic Explicitly list transitive VTK dependencies because _get_dependencies_recurse used in vtkAddon/CMake/vtkMacroKitPythonWrap.cmake does not recurse over dependencies that are VTK python wrapped. Before: >>> slicer.modules.cameras.logic() (SlicerBaseLogic.vtkSlicerModuleLogic)0x7fe68dea2588 After: >>> slicer.modules.cameras.logic() (vtkSlicerCamerasModuleLogic.vtkSlicerCamerasModuleLogic)0x7fbed69c42e8 * To avoid configuration warning and link errors like the following, it is important to publish relevant tag onto the Slicer/VTK fork. Simply commenting the call to "determine_version" was not the correct approach. CMake Warning at CMake/VTKDetermineVersion.cmake:64 (message): Version from git (7.0.0) disagrees with hard coded version (9.0.20200825). Either update the git tags or version.txt. macOS link error: ld: malformed 64-bit a.b.c.d.e version number: 9.0.20200825 clang: error: linker command failed with exit code 1 (use -v to see invocation) --------------------------------------------- List of VTK changes integrated on top of Slicer/VTK@3fa220f28e5: $ git shortlog 3fa220f..2f4e011bfc --no-merges Davide Punzo (1): [backport MR-7193] ENH: add double click events Jean-Christophe Fillion-Robin (3): COMP: Remove vtk-m submodule COMP: Remove FindTBB and expect VTK to be configured with TBB_DIR BUG: Update vtkPythonUtil to disable relative import causing crash for Slicer modules --------------------------------------------- List of CTK changes: $ git shortlog 92d2191b..48e4a3f3 --no-merges Andras Lasso (1): COMP: Fix build error in ctkLDAPExpr.cpp Jean-Christophe Fillion-Robin (3): COMP: Fix build of ctkVTKWidgetsUtilsTestImageConversion using Qt 5.10 COMP: Remove support for building against VTK <= 5.8 COMP: Add support for building against VTK >= 8.90 al-sabr (1): Add files via upload (commontk/CTK#930) --------------------------------------------- List of vtkAddon changes: $ git shortlog a64d854..5df87de --no-merges Jean-Christophe Fillion-Robin (1): ENH: Add support for building against VTK >= 8.90 --------------------------------------------- List of SurfaceToolbox changes: $ git shortlog 28b2567..501a0c7 --no-merges Jean-Christophe Fillion-Robin (1): COMP: Fix wrapping of vtkSlicerDynamicModeler classes with VTK >= 8.90 Co-authored-by: Andras Lasso <lasso@queensu.ca> Co-authored-by: Csaba Pinter <pinter.csaba@gmail.com> Co-authored-by: David Gobbi <david.gobbi@gmail.com> Co-authored-by: Davide Punzo <punzodavide@hotmail.it> Co-authored-by: Jean-Christophe Fillion-Robin <jchris.fillionr@kitware.com>
jcfr
added a commit
to jcfr/Slicer
that referenced
this pull request
Oct 1, 2020
This commit enables support for building Slicer against VTK 8.2.0 or 9.0.0 by setting the option Slicer_VTK_VERSION_MAJOR. By default, Slicer_VTK_VERSION_MAJOR is set to 8 Notes: * VTK_USE_FILE is included only if VTK <= 8.90. * To support building against both version of VTK and use the relevant names for targets and components, variables VTK_TARGET_PREFIX and VTK_COMPONENT_PREFIX have been introduced. * vtkArchive: Change call from "GetCurrentWorkingDirectory(true)" to "GetCurrentWorkingDirectory()", since the default parameter value was "true", it does not change the behavior. Change originally introduced in Kitware/VTK@d33a5e5e6 * Disable verbosity associated with vtkLogger to ensure all messages are captured by the existing logging infrastructure. * Update VTK removing FindTBB and expect VTK to be configured with TBB_DIR. Alternative approach where passing CMake variables satisfying both ITK and VTK have been considered but we would have required to update every project doing a "find_package(ITK)" because "ITKVTKGlue" only configure the value TBB_DIR in the generated module files. For reference, error encountered where like the following: CMake Error at D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:116 (message): Required library TBB not found. Call Stack (most recent call first): D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:352 (findpkg_finish) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:538 (find_package) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/vtk-config.cmake:138 (include) D:/T/S-b/VTK-build/vtk-config.cmake:1 (include) Modules/Bridge/VtkGlue/itk-module-init.cmake:9 (find_package) CMake/ITKModuleEnablement.cmake:321 (include) CMakeLists.txt:478 (include) CTK configuration error: CMake Error at D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:116 (message): Required library TBB not found. Call Stack (most recent call first): D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:352 (findpkg_finish) 10000 D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:538 (find_package) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/vtk-config.cmake:138 (include) D:/T/S-b/VTK-build/vtk-config.cmake:1 (include) D:/T/S-b/ITK-build/lib/cmake/ITK-5.1/Modules/ITKVtkGlue.cmake:30 (find_package) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:76 (include) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:31 (itk_module_load) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:129 (_itk_module_config_recurse) D:/T/S-b/ITK-build/ITKConfig.cmake:77 (itk_module_config) CMakeLists.txt:1004 (find_package) * Fix packaging of VTK 9 components on windows and linux specifying expected component names to install: "runtime" and "python" if slicer is built with python support. * Update wrapping infrastructure to support VTK >= 8.90: - Support wrapping of VTK based classes independently of the version of VTK being used, a custom copy of vtkWrapHierarchy, vtkWrapPython and vtkWrapperInit.data.in have been added. - With VTK >= 8.90, merge Python with PythonD libraries - Update vtkWrapPython to make sure remote modules targets are ignored when wrapping Slicer classes. - Update VTK wrapping CMake modules to ensure hierarchy files of dependencies are passed to both vtkWrapHierarchy and vtkWrapPython tools using the --types parameter. See See https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100 VTK has also been updated to disable the relative import generated in the "*InitImpl.cxx" files. It led to the generation of code similar to the following which was failing when trying to perform the relative import of Slicer wrapped modules using "vtkPythonUtil::ImportModule": const char *depends[4] = { "vtkAddonPython", "vtkITKPython", "vtkSegmentationCorePython", "vtkTeemPython", }; for (int i = 0; i < 4; i++) { if (!vtkPythonUtil::ImportModule(depends[i], d)) { return PyErr_Format(PyExc_ImportError, "Failed to load MRMLCorePython: No module named %s", depends[i]); } } - Fix slicer.util.importModuleObjects to work with VTK >- 8.90 Since python module generated using VTK>=8.90 already take care of importing their dependencies using `vtkPythonUtil::ImportModule`, the sys.modules dict is updated early on. To accomodate this, this commit changes the test checking if items of an object have already been imported into the target one. - Fix wrapping of module logic Explicitly list transitive VTK dependencies because _get_dependencies_recurse used in vtkAddon/CMake/vtkMacroKitPythonWrap.cmake does not recurse over dependencies that are VTK python wrapped. Before: >>> slicer.modules.cameras.logic() (SlicerBaseLogic.vtkSlicerModuleLogic)0x7fe68dea2588 After: >>> slicer.modules.cameras.logic() (vtkSlicerCamerasModuleLogic.vtkSlicerCamerasModuleLogic)0x7fbed69c42e8 * To avoid configuration warning and link errors like the following, it is important to publish relevant tag onto the Slicer/VTK fork. Simply commenting the call to "determine_version" was not the correct approach. CMake Warning at CMake/VTKDetermineVersion.cmake:64 (message): Version from git (7.0.0) disagrees with hard coded version (9.0.20200825). Either update the git tags or version.txt. macOS link error: ld: malformed 64-bit a.b.c.d.e version number: 9.0.20200825 clang: error: linker command failed with exit code 1 (use -v to see invocation) --------------------------------------------- List of VTK 9 changes integrated on top of Slicer/VTK@3fa220f28e5: $ git shortlog 3fa220f..2f4e011bfc --no-merges Davide Punzo (1): [backport MR-7193] ENH: add double click events Jean-Christophe Fillion-Robin (3): COMP: Remove vtk-m submodule COMP: Remove FindTBB and expect VTK to be configured with TBB_DIR BUG: Update vtkPythonUtil to disable relative import causing crash for Slicer modules --------------------------------------------- List of VTK8 changes: $ git shortlog 97904fdcc7..9f91f8a3fd --no-merges Jean-Christophe Fillion-Robin (1): COMP: Remove FindTBB and expect VTK to be configured with TBB_DIR --------------------------------------------- List of CTK changes: $ git shortlog 92d2191b..48e4a3f3 --no-merges Andras Lasso (1): COMP: Fix build error in ctkLDAPExpr.cpp Jean-Christophe Fillion-Robin (3): COMP: Fix build of ctkVTKWidgetsUtilsTestImageConversion using Qt 5.10 COMP: Remove support for building against VTK <= 5.8 COMP: Add support for building against VTK >= 8.90 al-sabr (1): Add files via upload (commontk/CTK#930) --------------------------------------------- List of vtkAddon changes: $ git shortlog a64d854..5df87de --no-merges Jean-Christophe Fillion-Robin (1): ENH: Add support for building against VTK >= 8.90 --------------------------------------------- List of SurfaceToolbox changes: $ git shortlog 28b2567..501a0c7 --no-merges Jean-Christophe Fillion-Robin (1): COMP: Fix wrapping of vtkSlicerDynamicModeler classes with VTK >= 8.90 Co-authored-by: Andras Lasso <lasso@queensu.ca> Co-authored-by: Csaba Pinter <pinter.csaba@gmail.com> Co-authored-by: David Gobbi <david.gobbi@gmail.com> Co-authored-by: Davide Punzo <punzodavide@hotmail.it> Co-authored-by: Jean-Christophe Fillion-Robin <jchris.fillionr@kitware.com>
jcfr
added a commit
to jcfr/Slicer
that referenced
this pull request
Oct 1, 2020
This commit enables support for building Slicer against VTK 8.2.0 or 9.0.0 by setting the option Slicer_VTK_VERSION_MAJOR. By default, Slicer_VTK_VERSION_MAJOR is set to 8 Notes: * VTK_USE_FILE is included only if VTK <= 8.90. * To support building against both version of VTK and use the relevant names for targets and components, variables VTK_TARGET_PREFIX and VTK_COMPONENT_PREFIX have been introduced. * vtkArchive: Change call from "GetCurrentWorkingDirectory(true)" to "GetCurrentWorkingDirectory()", since the default parameter value was "true", it does not change the behavior. Change originally introduced in Kitware/VTK@d33a5e5e6 * Disable verbosity associated with vtkLogger to ensure all messages are captured by the existing logging infrastructure. * Update VTK removing FindTBB and expect VTK to be configured with TBB_DIR. Alternative approach where passing CMake variables satisfying both ITK and VTK have been considered but we would have required to update every project doing a "find_package(ITK)" because "ITKVTKGlue" only configure the value TBB_DIR in the generated module files. For reference, error encountered where like the following: CMake Error at D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:116 (message): Required library TBB not found. Call Stack (most recent call first): D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:352 (findpkg_finish) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:538 (find_package) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/vtk-config.cmake:138 (include) D:/T/S-b/VTK-build/vtk-config.cmake:1 (include) Modules/Bridge/VtkGlue/itk-module-init.cmake:9 (find_package) CMake/ITKModuleEnablement.cmake:321 (include) CMakeLists.txt:478 (include) CTK configuration error: CMake Error at D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:116 (message): Required library TBB not found. Call Stack (most recent call first): D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:352 (findpkg_finish) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:538 (find_package) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/vtk-config.cmake:138 (include) D:/T/S-b/VTK-build/vtk-config.cmake:1 (include) D:/T/S-b/ITK-build/lib/cmake/ITK-5.1/Modules/ITKVtkGlue.cmake:30 (find_package) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:76 (include) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:31 (itk_module_load) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:129 (_itk_module_config_recurse) D:/T/S-b/ITK-build/ITKConfig.cmake:77 (itk_module_config) CMakeLists.txt:1004 (find_package) * Fix packaging of VTK 9 components on windows and linux specifying expected component names to install: "runtime" and "python" if slicer is built with python support. * Force CMAKE_INSTALL_LIBDIR value to "lib" to prevent "lib64" from being used on Linux. * Update wrapping infrastructure to support VTK >= 8.90: - Support wrapping of VTK based classes independently of the version of VTK being used, a custom copy of vtkWrapHierarchy, vtkWrapPython and vtkWrapperInit.data.in have been added. - With VTK >= 8.90, merge Python with PythonD libraries - Update vtkWrapPython to make sure remote modules targets are ignored when wrapping Slicer classes. - Update VTK wrapping CMake modules to ensure hierarchy files of dependencies are passed to both vtkWrapHierarchy and vtkWrapPython tools using the --types parameter. See See https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100 VTK has also been updated to disable the relative import generated in the "*InitImpl.cxx" files. It led to the generation of code similar to the following which was failing when trying to perform the relative import of Slicer wrapped modules using "vtkPythonUtil::ImportModule": const char *depends[4] = { "vtkAddonPython", "vtkITKPython", "vtkSegmentationCorePython", "vtkTeemPython", }; for (int i = 0; i < 4; i++) { if (!vtkPythonUtil::ImportModule(depends[i], d)) { return PyErr_Format(PyExc_ImportError, "Failed to load MRMLCorePython: No module named %s", depends[i]); } } - Fix slicer.util.importModuleObjects to work with VTK >- 8.90 Since python module generated using VTK>=8.90 already take care of importing their dependencies using `vtkPythonUtil::ImportModule`, the sys.modules dict is updated early on. To accomodate this, this commit changes the test checking if items of an object have already been imported into the target one. - Fix wrapping of module logic Explicitly list transitive VTK dependencies because _get_dependencies_recurse used in vtkAddon/CMake/vtkMacroKitPythonWrap.cmake does not recurse over dependencies that are VTK python wrapped. Before: >>> slicer.modules.cameras.logic() (SlicerBaseLogic.vtkSlicerModuleLogic)0x7fe68dea2588 After: >>> slicer.modules.cameras.logic() (vtkSlicerCamerasModuleLogic.vtkSlicerCamerasModuleLogic)0x7fbed69c42e8 * To avoid configuration warning and link errors like the following, it is important to publish relevant tag onto the Slicer/VTK fork. Simply commenting the call to "determine_version" was not the correct approach. CMake Warning at CMake/VTKDetermineVersion.cmake:64 (message): Version from git (7.0.0) disagrees with hard coded version (9.0.20200825). Either update the git tags or version.txt. macOS link error: ld: malformed 64-bit a.b.c.d.e version number: 9.0.20200825 clang: error: linker command failed with exit code 1 (use -v to see invocation) --------------------------------------------- List of VTK 9 changes integrated on top of Slicer/VTK@3fa220f28e5: $ git shortlog 3fa220f..2f4e011bfc --no-merges Davide Punzo (1): [backport MR-7193] ENH: add double click events Jean-Christophe Fillion-Robin (3): COMP: Remove vtk-m submodule COMP: Remove FindTBB and expect VTK to be configured with TBB_DIR BUG: Update vtkPythonUtil to disable relative import causing crash for Slicer modules --------------------------------------------- List of VTK8 changes: $ git shortlog 97904fdcc7..9f91f8a3fd --no-merges Jean-Christophe Fillion-Robin (1): COMP: Remove FindTBB and expect VTK to be configured with TBB_DIR --------------------------------------------- List of CTK changes: $ git shortlog 92d2191b..48e4a3f3 --no-merges Andras Lasso (1): COMP: Fix build error in ctkLDAPExpr.cpp Jean-Christophe Fillion-Robin (3): COMP: Fix build of ctkVTKWidgetsUtilsTestImageConversion using Qt 5.10 COMP: Remove support for building against VTK <= 5.8 COMP: Add support for building against VTK >= 8.90 al-sabr (1): Add files via upload (commontk/CTK#930) --------------------------------------------- List of vtkAddon changes: $ git shortlog a64d854..5df87de --no-merges Jean-Christophe Fillion-Robin (1): ENH: Add support for building against VTK >= 8.90 --------------------------------------------- List of SurfaceToolbox changes: $ git shortlog 28b2567..501a0c7 --no-merges Jean-Christophe Fillion-Robin (1): COMP: Fix wrapping of vtkSlicerDynamicModeler classes with VTK >= 8.90 Co-authored-by: Andras Lasso <lasso@queensu.ca> Co-authored-by: Csaba Pinter <pinter.csaba@gmail.com> Co-authored-by: David Gobbi <david.gobbi@gmail.com> Co-authored-by: Davide Punzo <punzodavide@hotmail.it> Co-authored-by: Jean-Christophe Fillion-Robin <jchris.fillionr@kitware.com>
jcfr
added a commit
to jcfr/Slicer
that referenced
this pull request
Oct 1, 2020
This commit enables support for building Slicer against VTK 8.2.0 or 9.0.0 by setting the option Slicer_VTK_VERSION_MAJOR. By default, Slicer_VTK_VERSION_MAJOR is set to 8 Notes: * VTK_USE_FILE is included only if VTK <= 8.90. * To support building against both version of VTK and use the relevant names for targets and components, variables VTK_TARGET_PREFIX and VTK_COMPONENT_PREFIX have been introduced. * vtkArchive: Change call from "GetCurrentWorkingDirectory(true)" to "GetCurrentWorkingDirectory()", since the default parameter value was "true", it does not change the behavior. Change originally introduced in Kitware/VTK@d33a5e5e6 * Disable verbosity associated with vtkLogger to ensure all messages are captured by the existing logging infrastructure. * Update VTK removing FindTBB and expect VTK to be configured with TBB_DIR. Alternative approach where passing CMake variables satisfying both ITK and VTK have been considered but we would have required to update every project doing a "find_package(ITK)" because "ITKVTKGlue" only configure the value TBB_DIR in the generated module files. For reference, error encountered where like the following: CMake Error at D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:116 (message): Required library TBB not found. Call Stack (most recent call first): D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:352 (findpkg_finish) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:538 (find_package) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/vtk-config.cmake:138 (include) D:/T/S-b/VTK-build/vtk-config.cmake:1 (include) Modules/Bridge/VtkGlue/itk-module-init.cmake:9 (find_package) CMake/ITKModuleEnablement.cmake:321 (include) CMakeLists.txt:478 (include) CTK configuration error: CMake Error at D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:116 (message): Required library TBB not found. Call Stack (most recent call first): D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:352 (findpkg_finish) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:538 (find_package) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/vtk-config.cmake:138 (include) D:/T/S-b/VTK-build/vtk-config.cmake:1 (include) D:/T/S-b/ITK-build/lib/cmake/ITK-5.1/Modules/ITKVtkGlue.cmake:30 (find_package) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:76 (include) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:31 (itk_module_load) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:129 (_itk_module_config_recurse) D:/T/S-b/ITK-build/ITKConfig.cmake:77 (itk_module_config) CMakeLists.txt:1004 (find_package) * Fix packaging of VTK 9 components on windows and linux specifying expected component names to install: "runtime" and "python" if slicer is built with python support. * Force CMAKE_INSTALL_LIBDIR value to "lib" to prevent "lib64" from being used on Linux. * Update wrapping infrastructure to support VTK >= 8.90: - Support wrapping of VTK based classes independently of the version of VTK being used, a custom copy of vtkWrapHierarchy, vtkWrapPython and vtkWrapperInit.data.in have been added. - With VTK >= 8.90, merge Python with PythonD libraries - Update vtkWrapPython to make sure remote modules targets are ignored when wrapping Slicer classes. - Update VTK wrapping CMake modules to ensure hierarchy files of dependencies are passed to both vtkWrapHierarchy and vtkWrapPython tools using the --types parameter. See See https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100 VTK has also been updated to disable the relative import generated in the "*InitImpl.cxx" files. It led to the generation of code similar to the following which was failing when trying to perform the relative import of Slicer wrapped modules using "vtkPythonUtil::ImportModule": const char *depends[4] = { "vtkAddonPython", "vtkITKPython", "vtkSegmentationCorePython", "vtkTeemPython", }; for (int i = 0; i < 4; i++) { if (!vtkPythonUtil::ImportModule(depends[i], d)) { return PyErr_Format(PyExc_ImportError, "Failed to load MRMLCorePython: No module named %s", depends[i]); } } - Fix slicer.util.importModuleObjects to work with VTK >- 8.90 Since python module generated using VTK>=8.90 already take care of importing their dependencies using `vtkPythonUtil::ImportModule`, the sys.modules dict is updated early on. To accomodate this, this commit changes the test checking if items of an object have already been imported into the target one. - Fix wrapping of module logic Explicitly list transitive VTK dependencies because _get_dependencies_recurse used in vtkAddon/CMake/vtkMacroKitPythonWrap.cmake does not recurse over dependencies that are VTK python wrapped. Before: >>> slicer.modules.cameras.logic() (SlicerBaseLogic.vtkSlicerModuleLogic)0x7fe68dea2588 After: >>> slicer.modules.cameras.logic() (vtkSlicerCamerasModuleLogic.vtkSlicerCamerasModuleLogic)0x7fbed69c42e8 * To avoid configuration warning and link errors like the following, it is important to publish relevant tag onto the Slicer/VTK fork. Simply commenting the call to "determine_version" was not the correct approach. CMake Warning at CMake/VTKDetermineVersion.cmake:64 (message): Version from git (7.0.0) disagrees with hard coded version (9.0.20200825). Either update the git tags or version.txt. macOS link error: ld: malformed 64-bit a.b.c.d.e version number: 9.0.20200825 clang: error: linker command failed with exit code 1 (use -v to see invocation) --------------------------------------------- List of VTK 9 changes integrated on top of Slicer/VTK@3fa220f28e5: $ git shortlog 3fa220f..2f4e011bfc --no-merges Davide Punzo (1): [backport MR-7193] ENH: add double click events Jean-Christophe Fillion-Robin (3): COMP: Remove vtk-m submodule COMP: Remove FindTBB and expect VTK to be configured with TBB_DIR BUG: Update vtkPythonUtil to disable relative import causing crash for Slicer modules --------------------------------------------- List of CTK changes: $ git shortlog 92d2191b..48e4a3f3 --no-merges Andras Lasso (1): COMP: Fix build error in ctkLDAPExpr.cpp Jean-Christophe Fillion-Robin (3): COMP: Fix build of ctkVTKWidgetsUtilsTestImageConversion using Qt 5.10 COMP: Remove support for building against VTK <= 5.8 COMP: Add support for building against VTK >= 8.90 al-sabr (1): Add files via upload (commontk/CTK#930) --------------------------------------------- List of vtkAddon changes: $ git shortlog a64d854..5df87de --no-merges Jean-Christophe Fillion-Robin (1): ENH: Add support for building against VTK >= 8.90 --------------------------------------------- List of SurfaceToolbox changes: $ git shortlog 28b2567..501a0c7 --no-merges Jean-Christophe Fillion-Robin (1): COMP: Fix wrapping of vtkSlicerDynamicModeler classes with VTK >= 8.90 Co-authored-by: Andras Lasso <lasso@queensu.ca> Co-authored-by: Csaba Pinter <pinter.csaba@gmail.com> Co-authored-by: David Gobbi <david.gobbi@gmail.com> Co-authored-by: Davide Punzo <punzodavide@hotmail.it> Co-authored-by: Jean-Christophe Fillion-Robin <jchris.fillionr@kitware.com>
jcfr
added a commit
to Slicer/Slicer
that referenced
this pull request
Oct 1, 2020
This commit enables support for building Slicer against VTK 8.2.0 or 9.0.0 by setting the option Slicer_VTK_VERSION_MAJOR. By default, Slicer_VTK_VERSION_MAJOR is set to 8 Notes: * VTK_USE_FILE is included only if VTK <= 8.90. * To support building against both version of VTK and use the relevant names for targets and components, variables VTK_TARGET_PREFIX and VTK_COMPONENT_PREFIX have been introduced. * vtkArchive: Change call from "GetCurrentWorkingDirectory(true)" to "GetCurrentWorkingDirectory()", since the default parameter value was "true", it does not change the behavior. Change originally introduced in Kitware/VTK@d33a5e5e6 * Disable verbosity associated with vtkLogger to ensure all messages are captured by the existing logging infrastructure. * Update VTK removing FindTBB and expect VTK to be configured with TBB_DIR. Alternative approach where passing CMake variables satisfying both ITK and VTK have been considered but we would have required to update every project doing a "find_package(ITK)" because "ITKVTKGlue" only configure the value TBB_DIR in the generated module files. For reference, error encountered where like the following: CMake Error at D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:116 (message): Required library TBB not found. Call Stack (most recent call first): D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:352 (findpkg_finish) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:538 (find_package) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/vtk-config.cmake:138 (include) D:/T/S-b/VTK-build/vtk-config.cmake:1 (include) Modules/Bridge/VtkGlue/itk-module-init.cmake:9 (find_package) CMake/ITKModuleEnablement.cmake:321 (include) CMakeLists.txt:478 (include) CTK configuration error: CMake Error at D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:116 (message): Required library TBB not found. Call Stack (most recent call first): D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:352 (findpkg_finish) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:538 (find_package) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/vtk-config.cmake:138 (include) D:/T/S-b/VTK-build/vtk-config.cmake:1 (include) D:/T/S-b/ITK-build/lib/cmake/ITK-5.1/Modules/ITKVtkGlue.cmake:30 (find_package) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:76 (include) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:31 (itk_module_load) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:129 (_itk_module_config_recurse) D:/T/S-b/ITK-build/ITKConfig.cmake:77 (itk_module_config) CMakeLists.txt:1004 (find_package) * Fix packaging of VTK 9 components on windows and linux specifying expected component names to install: "runtime" and "python" if slicer is built with python support. * Force CMAKE_INSTALL_LIBDIR value to "lib" to prevent "lib64" from being used on Linux. * Update wrapping infrastructure to support VTK >= 8.90: - Support wrapping of VTK based classes independently of the version of VTK being used, a custom copy of vtkWrapHierarchy, vtkWrapPython and vtkWrapperInit.data.in have been added. - With VTK >= 8.90, merge Python with PythonD libraries - Update vtkWrapPython to make sure remote modules targets are ignored when wrapping Slicer classes. - Update VTK wrapping CMake modules to ensure hierarchy files of dependencies are passed to both vtkWrapHierarchy and vtkWrapPython tools using the --types parameter. See See https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100 VTK has also been updated to disable the relative import generated in the "*InitImpl.cxx" files. It led to the generation of code similar to the following which was failing when trying to perform the relative import of Slicer wrapped modules using "vtkPythonUtil::ImportModule": const char *depends[4] = { "vtkAddonPython", "vtkITKPython", "vtkSegmentationCorePython", "vtkTeemPython", }; for (int i = 0; i < 4; i++) { if (!vtkPythonUtil::ImportModule(depends[i], d)) { return PyErr_Format(PyExc_ImportError, "Failed to load MRMLCorePython: No module named %s", depends[i]); } } - Fix slicer.util.importModuleObjects to work with VTK >- 8.90 Since python module generated using VTK>=8.90 already take care of importing their dependencies using `vtkPythonUtil::ImportModule`, the sys.modules dict is updated early on. To accomodate this, this commit changes the test checking if items of an object have already been imported into the target one. - Fix wrapping of module logic Explicitly list transitive VTK dependencies because _get_dependencies_recurse used in vtkAddon/CMake/vtkMacroKitPythonWrap.cmake does not recurse over dependencies that are VTK python wrapped. Before: >>> slicer.modules.cameras.logic() (SlicerBaseLogic.vtkSlicerModuleLogic)0x7fe68dea2588 After: >>> slicer.modules.cameras.logic() (vtkSlicerCamerasModuleLogic.vtkSlicerCamerasModuleLogic)0x7fbed69c42e8 * To avoid configuration warning and link errors like the following, it is important to publish relevant tag onto the Slicer/VTK fork. Simply commenting the call to "determine_version" was not the correct approach. CMake Warning at CMake/VTKDetermineVersion.cmake:64 (message): Version from git (7.0.0) disagrees with hard coded version (9.0.20200825). Either update the git tags or version.txt. macOS link error: ld: malformed 64-bit a.b.c.d.e version number: 9.0.20200825 clang: error: linker command failed with exit code 1 (use -v to see invocation) --------------------------------------------- List of VTK 9 changes integrated on top of Slicer/VTK@3fa220f28e5: $ git shortlog 3fa220f..2f4e011bfc --no-merges Davide Punzo (1): [backport MR-7193] ENH: add double click events Jean-Christophe Fillion-Robin (3): COMP: Remove vtk-m submodule COMP: Remove FindTBB and expect VTK to be configured with TBB_DIR BUG: Update vtkPythonUtil to disable relative import causing crash for Slicer modules --------------------------------------------- List of CTK changes: $ git shortlog 92d2191b..48e4a3f3 --no-merges Andras Lasso (1): COMP: Fix build error in ctkLDAPExpr.cpp Jean-Christophe Fillion-Robin (3): COMP: Fix build of ctkVTKWidgetsUtilsTestImageConversion using Qt 5.10 COMP: Remove support for building against VTK <= 5.8 COMP: Add support for building against VTK >= 8.90 al-sabr (1): Add files via upload (commontk/CTK#930) --------------------------------------------- List of vtkAddon changes: $ git shortlog a64d854..5df87de --no-merges Jean-Christophe Fillion-Robin (1): ENH: Add support for building against VTK >= 8.90 --------------------------------------------- List of SurfaceToolbox changes: $ git shortlog 28b2567..501a0c7 --no-merges Jean-Christophe Fillion-Robin (1): COMP: Fix wrapping of vtkSlicerDynamicModeler classes with VTK >= 8.90 Co-authored-by: Andras Lasso <lasso@queensu.ca> Co-authored-by: Csaba Pinter <pinter.csaba@gmail.com> Co-authored-by: David Gobbi <david.gobbi@gmail.com> Co-authored-by: Davide Punzo <punzodavide@hotmail.it> Co-authored-by: Jean-Christophe Fillion-Robin <jchris.fillionr@kitware.com>
lassoan
added a commit
to lassoan/SlicerLegacyModules
that referenced
this pull request
Oct 25, 2021
This commit enables support for building Slicer against VTK 8.2.0 or 9.0.0 by setting the option Slicer_VTK_VERSION_MAJOR. By default, Slicer_VTK_VERSION_MAJOR is set to 8 Notes: * VTK_USE_FILE is included only if VTK <= 8.90. * To support building against both version of VTK and use the relevant names for targets and components, variables VTK_TARGET_PREFIX and VTK_COMPONENT_PREFIX have been introduced. * vtkArchive: Change call from "GetCurrentWorkingDirectory(true)" to "GetCurrentWorkingDirectory()", since the default parameter value was "true", it does not change the behavior. Change originally introduced in Kitware/VTK@d33a5e5e6 * Disable verbosity associated with vtkLogger to ensure all messages are captured by the existing logging infrastructure. * Update VTK removing FindTBB and expect VTK to be configured with TBB_DIR. Alternative approach where passing CMake variables satisfying both ITK and VTK have been considered but we would have required to update every project doing a "find_package(ITK)" because "ITKVTKGlue" only configure the value TBB_DIR in the generated module files. For reference, error encountered where like the following: CMake Error at D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:116 (message): Required library TBB not found. Call Stack (most recent call first): D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:352 (findpkg_finish) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:538 (find_package) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/vtk-config.cmake:138 (include) D:/T/S-b/VTK-build/vtk-config.cmake:1 (include) Modules/Bridge/VtkGlue/itk-module-init.cmake:9 (find_package) CMake/ITKModuleEnablement.cmake:321 (include) CMakeLists.txt:478 (include) CTK configuration error: CMake Error at D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:116 (message): Required library TBB not found. Call Stack (most recent call first): D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/FindTBB.cmake:352 (findpkg_finish) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/VTK-vtk-module-find-packages.cmake:538 (find_package) D:/T/S-b/VTK-build/lib/cmake/vtk-9.0/vtk-config.cmake:138 (include) D:/T/S-b/VTK-build/vtk-config.cmake:1 (include) D:/T/S-b/ITK-build/lib/cmake/ITK-5.1/Modules/ITKVtkGlue.cmake:30 (find_package) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:76 (include) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:31 (itk_module_load) D:/T/S-b/ITK/CMake/ITKModuleAPI.cmake:129 (_itk_module_config_recurse) D:/T/S-b/ITK-build/ITKConfig.cmake:77 (itk_module_config) CMakeLists.txt:1004 (find_package) * Fix packaging of VTK 9 components on windows and linux specifying expected component names to install: "runtime" and "python" if slicer is built with python support. * Force CMAKE_INSTALL_LIBDIR value to "lib" to prevent "lib64" from being used on Linux. * Update wrapping infrastructure to support VTK >= 8.90: - Support wrapping of VTK based classes independently of the version of VTK being used, a custom copy of vtkWrapHierarchy, vtkWrapPython and vtkWrapperInit.data.in have been added. - With VTK >= 8.90, merge Python with PythonD libraries - Update vtkWrapPython to make sure remote modules targets are ignored when wrapping Slicer classes. - Update VTK wrapping CMake modules to ensure hierarchy files of dependencies are passed to both vtkWrapHierarchy and vtkWrapPython tools using the --types parameter. See See https://discourse.vtk.org/t/issue-with-using-vtkpythonutil-getobjectfrompointer-for-custom-vtk-classes/4100 VTK has also been updated to disable the relative import generated in the "*InitImpl.cxx" files. It led to the generation of code similar to the following which was failing when trying to perform the relative import of Slicer wrapped modules using "vtkPythonUtil::ImportModule": const char *depends[4] = { "vtkAddonPython", "vtkITKPython", "vtkSegmentationCorePython", "vtkTeemPython", }; for (int i = 0; i < 4; i++) { if (!vtkPythonUtil::ImportModule(depends[i], d)) { return PyErr_Format(PyExc_ImportError, "Failed to load MRMLCorePython: No module named %s", depends[i]); } } - Fix slicer.util.importModuleObjects to work with VTK >- 8.90 Since python module generated using VTK>=8.90 already take care of importing their dependencies using `vtkPythonUtil::ImportModule`, the sys.modules dict is updated early on. To accomodate this, this commit changes the test checking if items of an object have already been imported into the target one. - Fix wrapping of module logic Explicitly list transitive VTK dependencies because _get_dependencies_recurse used in vtkAddon/CMake/vtkMacroKitPythonWrap.cmake does not recurse over dependencies that are VTK python wrapped. Before: >>> slicer.modules.cameras.logic() (SlicerBaseLogic.vtkSlicerModuleLogic)0x7fe68dea2588 After: >>> slicer.modules.cameras.logic() (vtkSlicerCamerasModuleLogic.vtkSlicerCamerasModuleLogic)0x7fbed69c42e8 * To avoid configuration warning and link errors like the following, it is important to publish relevant tag onto the Slicer/VTK fork. Simply commenting the call to "determine_version" was not the correct approach. CMake Warning at CMake/VTKDetermineVersion.cmake:64 (message): Version from git (7.0.0) disagrees with hard coded version (9.0.20200825). Either update the git tags or version.txt. macOS link error: ld: malformed 64-bit a.b.c.d.e version number: 9.0.20200825 clang: error: linker command failed with exit code 1 (use -v to see invocation) --------------------------------------------- List of VTK 9 changes integrated on top of Slicer/VTK@3fa220f28e5: $ git shortlog 3fa220f28e..2f4e011bfc --no-merges Davide Punzo (1): [backport MR-7193] ENH: add double click events Jean-Christophe Fillion-Robin (3): COMP: Remove vtk-m submodule COMP: Remove FindTBB and expect VTK to be configured with TBB_DIR BUG: Update vtkPythonUtil to disable relative import causing crash for Slicer modules --------------------------------------------- List of CTK changes: $ git shortlog 92d2191b..48e4a3f3 --no-merges Andras Lasso (1): COMP: Fix build error in ctkLDAPExpr.cpp Jean-Christophe Fillion-Robin (3): COMP: Fix build of ctkVTKWidgetsUtilsTestImageConversion using Qt 5.10 COMP: Remove support for building against VTK <= 5.8 COMP: Add support for building against VTK >= 8.90 al-sabr (1): Add files via upload (commontk/CTK#930) --------------------------------------------- List of vtkAddon changes: $ git shortlog a64d854..5df87de --no-merges Jean-Christophe Fillion-Robin (1): ENH: Add support for building against VTK >= 8.90 --------------------------------------------- List of SurfaceToolbox changes: $ git shortlog 28b2567..501a0c7 --no-merges Jean-Christophe Fillion-Robin (1): COMP: Fix wrapping of vtkSlicerDynamicModeler classes with VTK >= 8.90 Co-authore 5D86 d-by: Andras Lasso <lasso@queensu.ca> Co-authored-by: Csaba Pinter <pinter.csaba@gmail.com> Co-authored-by: David Gobbi <david.gobbi@gmail.com> Co-authored-by: Davide Punzo <punzodavide@hotmail.it> Co-authored-by: Jean-Christophe Fillion-Robin <jchris.fillionr@kitware.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Temporary solution for MS Visual Studio 2019 with PluginFramework.