VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2020-04-23T10:19:42-04:00https://gitlab.kitware.com/vtk/vtk/-/issues/17506Restore support for CastXML-based wrappers2020-04-23T10:19:42-04:00Ben BoeckelRestore support for CastXML-based wrappersActiViz (C# support) wraps VTK using [`castxml`](https://github.com/CastXML/CastXML) which needs code to actually compile in order to extract the information for wrapping. Between 8.1 and 8.2, two major changes were made in VTK related t...ActiViz (C# support) wraps VTK using [`castxml`](https://github.com/CastXML/CastXML) which needs code to actually compile in order to extract the information for wrapping. Between 8.1 and 8.2, two major changes were made in VTK related to wrapping:
- move from source file properties for excluding files from wrapping to using `__VTK_WRAP__` to hide classes that should not be wrapped; and
- move from external files for "hints" as to array sizes for methods with raw pointers to macros that VTK's wrapping tools understoon.
These were done so that installs of VTK had the same information as was available in the build of VTK itself. However, this basically assumed that `vtkWrappingTools` was used. This excluded support for tools like `castxml` because a class which is wrapped that included an excluded file basically removed the definition which causes compilation failures.
Instead of reusing `__VTK_WRAP__` in order to hide classes, attributes should be added to classes directly. Something like:
```c++
class VTK_WRAP_EXCLUDE VTKMODULE_EXPORT vtkExcludedClass
```
where in a normal build, `VTK_WRAP_EXCLUDE` expands to nothing. With `__VTK_WRAP__` defined, this should be `[[vtk::wrapexclude]]` or the like that can then be checked in VTK's wrappers and ActiViz in order to skip that class.
I suspect that once ActiViz can set `__VTK_WRAP__` again, the existing attribute definitions for `VTK_SIZEHINT` should suffice for information, but if not, the wrapping tools may need to support writing out the old hints file format like it writes out the hierarchy files.
Here is a list of headers hiding code behind `__VTK_WRAP__`. Headers changing base classes in order to hide templates and those hiding individual methods behind `__VTK_WRAP__` are excluded.
<details><summary>Header list</summary>
- `Accelerators/Vtkm/vtkmCellSetExplicit.h`
- `Accelerators/Vtkm/vtkmCellSetSingleType.h`
- `Accelerators/Vtkm/vtkmConnectivityExec.h`
- `Common/Core/SMP/OpenMP/vtkAtomic.h.in`
- `Common/Core/SMP/OpenMP/vtkSMPToolsInternal.h.in`
- `Common/Core/SMP/Sequential/vtkAtomic.h.in`
- `Common/Core/vtkDataArrayAccessor.h`
- `Common/Core/vtkDataArrayTupleRange_AOS.h`
- `Common/Core/vtkDataArrayTupleRange_Generic.h`
- `Common/Core/vtkDataArrayValueRange_AOS.h`
- `Common/Core/vtkDataArrayValueRange_Generic.h`
- `Common/Core/vtkLargeInteger.h`
- `Common/Core/vtkOStreamWrapper.h`
- `Common/Core/vtkSMPTools.h`
- `Common/DataModel/vtkDispatcher_Private.h`
- `Common/DataModel/vtkHyperTreeGridEntry.h`
- `Common/DataModel/vtkHyperTreeGridGeometryEntry.h`
- `Common/DataModel/vtkHyperTreeGridGeometryLevelEntry.h`
- `Common/DataModel/vtkHyperTreeGridLevelEntry.h`
- `IO/ADIOS/ADIOSAttribute.h`
- `IO/ADIOS/ADIOSDefs.h`
- `IO/ADIOS/ADIOSReader.h`
- `IO/ADIOS/ADIOSScalar.h`
- `IO/ADIOS/ADIOSUtilities.h`
- `IO/ADIOS/ADIOSVarInfo.h`
- `IO/ADIOS/ADIOSWriter.h`
- `IO/ADIOS/vtkADIOSDirTree.h`
- `IO/ADIOS/vtkADIOSUtilities.h`
- `IO/Exodus/vtkExodusIIReaderPrivate.h`
- `IO/Exodus/vtkExodusIIReaderVariableCheck.h`
- `IO/Import/vtkOBJImporterInternals.h`
- `IO/LSDyna/vtkLSDynaPart.h`
- `IO/LSDyna/vtkLSDynaPartCollection.h`
- `IO/SegY/vtkSegYReaderInternal.h`
- `IO/Xdmf2/vtkXdmfHeavyData.h`
- `IO/Xdmf2/vtkXdmfReaderInternal.h`
- `Parallel/MPI/vtkMPI.h`
- `Rendering/Core/vtkCIEDE2000.h`
- `Rendering/Core/vtkNoise200x200.h`
- `Rendering/LICOpenGL2/vtkLICNoiseHelper.h`
- `Rendering/LICOpenGL2/vtkSurfaceLICHelper.h`
- `Rendering/OpenGL2/vtkCocoaGLView.h`
- `Rendering/OpenGL2/vtkCocoaMacOSXSDKCompatibility.h`
- `Rendering/VolumeOpenGL2/vtkOpenGLTransferFunction2D.h`
- `Rendering/VolumeOpenGL2/vtkOpenGLVolumeGradientOpacityTable.h`
- `Rendering/VolumeOpenGL2/vtkOpenGLVolumeOpacityTable.h`
- `Rendering/VolumeOpenGL2/vtkOpenGLVolumeRGBTable.h`
- `Rendering/VolumeOpenGL2/vtkVolumeInputHelper.h`
- `Testing/Rendering/vtkRegressionTestImage.h`
</details>
Cc: @dgobbi @jjomier @brad.kinghttps://gitlab.kitware.com/vtk/vtk/-/issues/17888RFE: Need to be able to define JNILIB_DESTINATION2020-05-11T12:51:25-04:00Orion PoplawskiRFE: Need to be able to define JNILIB_DESTINATIONFedora installs JNI libraries into %{_libdir}/%{name}. Currently VTK forces it to be:
```
JNILIB_DESTINATION "${CMAKE_INSTALL_LIBDIR}/java/vtk-${CMAKE_SYSTEM_NAME}-${CMAKE_SYSTEM_PROCESSOR}"
```
Please allow setting this via a build ...Fedora installs JNI libraries into %{_libdir}/%{name}. Currently VTK forces it to be:
```
JNILIB_DESTINATION "${CMAKE_INSTALL_LIBDIR}/java/vtk-${CMAKE_SYSTEM_NAME}-${CMAKE_SYSTEM_PROCESSOR}"
```
Please allow setting this via a build option.9.0.1Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/19001SDPX: Parse generated files for SPDX generation2023-08-01T05:36:01-04:00Mathieu Westphal (Kitware)SDPX: Parse generated files for SPDX generationCurrently, SPDX generation (see here: https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10200) happens at build time before the module target.
However, it does no depend on all the sources files, which means some generated source files...Currently, SPDX generation (see here: https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10200) happens at build time before the module target.
However, it does no depend on all the sources files, which means some generated source files may be missing at generation time.
For now, these files are just dropped but technically it would be possible to add all files as dependencies, the same way the `hierarchy` target works.https://gitlab.kitware.com/vtk/vtk/-/issues/17823Show KWSys within VTK doc2020-03-31T08:31:41-04:00Mathieu Westphal (Kitware)Show KWSys within VTK docCurrently, KWSys doc is not visible anywhere, requiring to read the headers.
It would be nice to use doxygen and generate this doc within VTK.Currently, KWSys doc is not visible anywhere, requiring to read the headers.
It would be nice to use doxygen and generate this doc within VTK.https://gitlab.kitware.com/vtk/vtk/-/issues/17120Simplify the VTK-m and VTK SMP build options2018-10-23T12:35:27-04:00Robert MaynardSimplify the VTK-m and VTK SMP build optionsVTK-m and VTK SMP both need to know what backends they should built with. Currently VTK-m defers to VTKSMP but that should be inverted.
Instead we should find what of all backends can be built with VTK-m since it supports multiple at th...VTK-m and VTK SMP both need to know what backends they should built with. Currently VTK-m defers to VTKSMP but that should be inverted.
Instead we should find what of all backends can be built with VTK-m since it supports multiple at the same time.https://gitlab.kitware.com/vtk/vtk/-/issues/17826SOABI detection is incorrect on Windows2020-04-02T19:47:55-04:00Ben BoeckelSOABI detection is incorrect on WindowsPer @federico.miorelli in https://gitlab.kitware.com/vtk/vtk/-/issues/17816#note_720667
> I will add that when using this mechanism, the name of the pyd files that are generated is vtkCommonCore.None.pyd
Cc: @marc.chevrierPer @federico.miorelli in https://gitlab.kitware.com/vtk/vtk/-/issues/17816#note_720667
> I will add that when using this mechanism, the name of the pyd files that are generated is vtkCommonCore.None.pyd
Cc: @marc.chevrier9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18041sqllite module in 9.0.1 missing libdl link2020-11-11T15:33:58-05:00Joseph Wangsqllite module in 9.0.1 missing libdl linksqlite module in 9.0.1 uses dlopen, but is missing a libdl link
should add CMAKE_DL_LIBS to the CMakeFile.txtsqlite module in 9.0.1 uses dlopen, but is missing a libdl link
should add CMAKE_DL_LIBS to the CMakeFile.txtBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17478Static python failing2021-04-14T16:21:17-04:00Ben BoeckelStatic python failingSomething is blocking the loading of the modules added to the inittab. I have logs that they're there. If the modules are added to the top-level, they work, but if they're in the `vtkmodules` package, they fail. Needs investigation.Something is blocking the loading of the modules added to the inittab. I have logs that they're there. If the modules are added to the top-level, they work, but if they're in the `vtkmodules` package, they fail. Needs investigation.https://gitlab.kitware.com/vtk/vtk/-/issues/18099Stop importing `vtk` in tests2023-01-18T21:19:32-05:00Ben BoeckelStop importing `vtk` in testsMany Python tests import the `vtk` module. This ends up importing *every* VTK module. If just one module has a problem, every Python test ends up failing. Instead, tests should import the module and class from the `vtkmodules` package.
...Many Python tests import the `vtk` module. This ends up importing *every* VTK module. If just one module has a problem, every Python test ends up failing. Instead, tests should import the module and class from the `vtkmodules` package.
@mwestphal Here's an idea for a hackathon
Cc: @utkarsh.ayachit @vboleaDavid GobbiDavid Gobbihttps://gitlab.kitware.com/vtk/vtk/-/issues/17532Suggest implementations of implementable modules without any2019-03-21T17:26:54-04:00Ben BoeckelSuggest implementations of implementable modules without anyIf VTK is building modules which are `IMPLEMENTABLE`, but none declare that they `IMPLEMENTS` the module, output a warning that none are being built and offer suggestions for building modules which offer the module implementations.
Cc: ...If VTK is building modules which are `IMPLEMENTABLE`, but none declare that they `IMPLEMENTS` the module, output a warning that none are being built and offer suggestions for building modules which offer the module implementations.
Cc: @utkarsh.ayachit @scott.wittenburghttps://gitlab.kitware.com/vtk/vtk/-/issues/17721Support CMake 3.16 UNITY_BUILD2023-12-17T10:07:05-05:00Julien SchuellerSupport CMake 3.16 UNITY_BUILDI assume VTK built time can be reduced significantly using CMake 3.16 unity build support:
https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html
To get to a point where using ```cmake -DCMAKE_UNITY_BUILD=ON``` works we need 2 t...I assume VTK built time can be reduced significantly using CMake 3.16 unity build support:
https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html
To get to a point where using ```cmake -DCMAKE_UNITY_BUILD=ON``` works we need 2 things:
- Disable the UNITY_BUILD property of third-party dependencies targets (I tried, the build fails here first)
- Blacklist sources files that should be excluded from unity builds with the source file property SKIP_UNITY_BUILD_INCLUSION (static variables conflict, conflicting headers...)
what do you think @ben.boeckel ?https://gitlab.kitware.com/vtk/vtk/-/issues/18648Support for manylinux_aarch64?2024-01-26T15:35:05-05:00Hammad RehmanSupport for manylinux_aarch64?Are there any plans to include Pypi wheels for manylinux_aarch64 in future releases? Right now I'm having to build it from source with Python bindings.Are there any plans to include Pypi wheels for manylinux_aarch64 in future releases? Right now I'm having to build it from source with Python bindings.https://gitlab.kitware.com/vtk/vtk/-/issues/18107Support TBB 2021 version, which has backwards-incompatible changes2022-05-11T07:40:58-04:00Sean McBrideSupport TBB 2021 version, which has backwards-incompatible changesIt seems TBB from the 2020 version to the 2021 version made a bunch of backwards-incompatible changes. The installed result has moved headers around, renamed them, and god knows what more. Notably the `tbb_stddef.h` file that VTK looks...It seems TBB from the 2020 version to the 2021 version made a bunch of backwards-incompatible changes. The installed result has moved headers around, renamed them, and god knows what more. Notably the `tbb_stddef.h` file that VTK looks for is no longer there, and thus fails to build.
OpenCV had the same problem, recently fixed: https://github.com/opencv/opencv/issues/19358
The good news though is that TBB seems to have switched to using cmake, so that's nice at least!https://gitlab.kitware.com/vtk/vtk/-/issues/18223Synchronize `__init__.py` version number with the wheel build logic2021-05-27T11:45:37-04:00Ben BoeckelSynchronize `__init__.py` version number with the wheel build logic!8006 added `.dev` information to the version for wheels. We should sync this up with the logic in `__init__.py` at some point.
- [ ] @dgobbi started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8006#note_960318): ...!8006 added `.dev` information to the version for wheels. We should sync this up with the logic in `__init__.py` at some point.
- [ ] @dgobbi started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8006#note_960318): (+1 comment)
> The versioning scheme looks good to me, [`__init__.py`](https://gitlab.kitware.com/vtk/vtk/-/blob/22d5cd93/Wrapping/Python/vtkmodules/__init__.py.in#L58) will have to be synchronized with this at some point.https://gitlab.kitware.com/vtk/vtk/-/issues/17005Synchronize FindPythonLibs with upstream CMake2019-01-09T15:43:27-05:00Shawn WaldonSynchronize FindPythonLibs with upstream CMakeI was trying to make a debug build of ParaView on Windows (using CMake's Ninja generator, not sure if it matters). But the python modules were failing to link because the couldn't find `python36_d.lib`. It turns out our old FindPythonL...I was trying to make a debug build of ParaView on Windows (using CMake's Ninja generator, not sure if it matters). But the python modules were failing to link because the couldn't find `python36_d.lib`. It turns out our old FindPythonLibs.cmake in VTK was the culprit. Deleting it and letting the one from CMake 3.8.0-rc2 find the libraries resulted in a build that could link (but since it wasn't a clean configure I'm not sure what else might have broken, the variables from the old one were still there). We should update to use the one from upstream CMake.
@dgobbi I would have made an MR, but it is a non-trivial diff and I wasn't sure what I'd be breaking (and don't really have time at the moment to fix it). It looks like the updated one removes some variables that the one in VTK sets. If we update, we do need to update to the one from CMake 3.8 though since there was a bug in FindPythonLibs that is fixed in that release (cmake/cmake#16729). It would be nice to do this for VTK 8.0, but I realize that is very soon.
@ben.boeckelBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/19194TBB versions prior to TBB 2019 Update 9 does not guard target creation2023-12-19T07:41:53-05:00Dan LipsaTBB versions prior to TBB 2019 Update 9 does not guard target creationWe need to update VTK to use that version of TBB
See
https://gitlab.kitware.com/paraview/paraview/-/merge_requests/6375#note_1449745We need to update VTK to use that version of TBB
See
https://gitlab.kitware.com/paraview/paraview/-/merge_requests/6375#note_14497459.3https://gitlab.kitware.com/vtk/vtk/-/issues/18775Test changes required for ABI namespacing2023-01-13T06:38:11-05:00David ThompsonTest changes required for ABI namespacingIf we ever add a CI build that test ABI namespacing, `Common/Core/Testing/Cxx/TestInherits` will need to be updated. Preferably, VTK should provide a `VTK_ABI_NAMESPACE_NAME` macro during compilation so it can be stringified and included...If we ever add a CI build that test ABI namespacing, `Common/Core/Testing/Cxx/TestInherits` will need to be updated. Preferably, VTK should provide a `VTK_ABI_NAMESPACE_NAME` macro during compilation so it can be stringified and included in the test.
See [this discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9499#note_1297741) on !9499 for details.Ryan Krattigerryan.krattiger@kitware.comRyan Krattigerryan.krattiger@kitware.comhttps://gitlab.kitware.com/vtk/vtk/-/issues/17509Test dependencies can want modules that don't get enabled2023-11-06T22:50:22-05:00Ben BoeckelTest dependencies can want modules that don't get enabledTest dependencies can end up requesting modules that never get provided. This happens when a module is toposorted after one which has been scanned, but has a test dependency on a module that had not been decided yet. To fix, a followup s...Test dependencies can end up requesting modules that never get provided. This happens when a module is toposorted after one which has been scanned, but has a test dependency on a module that had not been decided yet. To fix, a followup scan should be performed using modules requested but for which a `_provided` boolean has not been set at all yet.
# How do I know I have this issue?
If you enable testing and you get an error similar to:
```
CMake Error at CMake/vtkModule.cmake:2416 (message):
The VTK::somedep dependency is missing for VTK::somedepender.
Call Stack (most recent call first):
CMakeLists.txt:335 (vtk_module_build)
```
that goes away when testing is disabled.
# I'm seeing this issue, what do I do?
You can explicitly enable the `VTK::somedepender` module with `-DVTK_MODULE_ENABLE_VTK_somedepender=WANT`. This will enable the module explicitly and request any dependencies it needs. Alternatively, you can enable the `VTK::somedep` module, but this may need to be repeated for each missing dependency.https://gitlab.kitware.com/vtk/vtk/-/issues/18744Testing: support running the test suite against a VTK wheel2022-12-22T20:03:20-05:00Ben BoeckelTesting: support running the test suite against a VTK wheelThere should be a mechanism to run the Python tests against a provided wheel. This would immensely help the verification of wheel builds (especially as they may have configurations only available in a wheel build; see !9748).
Cc: @banes...There should be a mechanism to run the Python tests against a provided wheel. This would immensely help the verification of wheel builds (especially as they may have configurations only available in a wheel build; see !9748).
Cc: @banesullivan @dgobbihttps://gitlab.kitware.com/vtk/vtk/-/issues/17510Tests fail under Windows 10 static debug build2019-02-06T15:12:31-05:00Aron HelserTests fail under Windows 10 static debug buildAfter I build windows 10 static debug, all tests that open a render window segfault. Specifically, I get this error before a nullptr access:
```
Generic Warning: In C:\akit\vtk\src\Rendering\Core\vtkRenderWindow.cxx, line 35
Error: no ov...After I build windows 10 static debug, all tests that open a render window segfault. Specifically, I get this error before a nullptr access:
```
Generic Warning: In C:\akit\vtk\src\Rendering\Core\vtkRenderWindow.cxx, line 35
Error: no override found for 'vtkRenderWindow'.
```
I'm using VS2017, with these changes from VTK defaults:
```
set(BUILD_SHARED_LIBS "OFF" CACHE BOOL "")
set(BUILD_TESTING "ON" CACHE BOOL "")
set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "")
```
cc: @ben.boeckel