VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2024-03-07T08:22:30-05:00https://gitlab.kitware.com/vtk/vtk/-/issues/19265OpenTURNS not correctly looked up/forwarded in generated cmake configs2024-03-07T08:22:30-05:00Alexander NeumannOpenTURNS not correctly looked up/forwarded in generated cmake configsProblem was that I add a linker error due to not being able to open `OT.lib`. As it turns out the OpenTURNS filter as `$<LINK_ONLY:OT>` where `OT` is a target if a `find_package` call for OpenTURNS would have been done. The module info d...Problem was that I add a linker error due to not being able to open `OT.lib`. As it turns out the OpenTURNS filter as `$<LINK_ONLY:OT>` where `OT` is a target if a `find_package` call for OpenTURNS would have been done. The module info does not contain the information for VTK to actually generate that `find_package` call to OpenTURNS.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/19264vtkExodusII name mangling not complete2024-03-07T12:00:55-05:00Alexander NeumannvtkExodusII name mangling not completeHad to devendor exodusII because of a symbol conflict. Name mangling seems to be incomplete for the vendored exodusII. Conflicting symbol is `exerrval`
Here is the patch to devendor:
[devendor_exodusII.patch](/uploads/ba534a9eb6506c4f3e...Had to devendor exodusII because of a symbol conflict. Name mangling seems to be incomplete for the vendored exodusII. Conflicting symbol is `exerrval`
Here is the patch to devendor:
[devendor_exodusII.patch](/uploads/ba534a9eb6506c4f3e10069ffa26acbf/devendor_exodusII.patch)Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/192329.3.0 fails to compile: error: incompatible function pointer types passing 'h...2024-03-22T08:39:33-04:00yurivict9.3.0 fails to compile: error: incompatible function pointer types passing 'herr_t (hid_t, const char *, const H5L_info2_t *, void *)' (aka 'int (long, const char *, const H5L_info2_t *, void *)') to parameter of type 'H5L_iterate1_t' (aka 'int (*)(long,```
/usr/ports/math/vtk9/work/VTK-9.3.0/ThirdParty/cgns/vtkcgns/src/adfh/ADFH.c:1127:34: warning: incompatible pointer types passing 'H5L_info2_t *' to parameter of type 'H5L_info1_t *' [-Wincompatible-pointer-types]
herr = H5Lget_info...```
/usr/ports/math/vtk9/work/VTK-9.3.0/ThirdParty/cgns/vtkcgns/src/adfh/ADFH.c:1127:34: warning: incompatible pointer types passing 'H5L_info2_t *' to parameter of type 'H5L_info1_t *' [-Wincompatible-pointer-types]
herr = H5Lget_info(id, D_LINK, &sb, H5P_DEFAULT);
^~~
/usr/local/include/H5Lpublic.h:1703:73: note: passing argument to parameter 'linfo' here
H5_DLL herr_t H5Lget_info1(hid_t loc_id, const char *name, H5L_info1_t *linfo /*out*/, hid_t lapl_id);
^
/usr/ports/math/vtk9/work/VTK-9.3.0/ThirdParty/cgns/vtkcgns/src/adfh/ADFH.c:1287:92: error: incompatible function pointer types passing 'herr_t (hid_t, const char *, const H5L_info2_t *, void *)' (aka 'int (long, const char *, const H5L_info2_t *, void *)') to parameter of type 'H5L_iterate1_t' (aka 'int (*)(long, const char *, const H5L_info1_t *, void *)') [-Wincompatible-function-pointer-types]
if (! is_link(id)) H5Literate_by_name(id, name, H5_INDEX_CRT_ORDER, H5_ITER_INC, NULL, delete_children, data, H5P_DEFAULT);
^~~~~~~~~~~~~~~
/usr/local/include/H5Lpublic.h:1908:87: note: passing argument to parameter 'op' here
H5_iter_order_t order, hsize_t *idx, H5L_iterate1_t op, void *op_data,
^
/usr/ports/math/vtk9/work/VTK-9.3.0/ThirdParty/cgns/vtkcgns/src/adfh/ADFH.c:1447:63: error: incompatible function pointer types passing 'herr_t (hid_t, const char *, const H5L_info2_t *, void *)' (aka 'int (long, const char *, const H5L_info2_t *, void *)') to parameter of type 'H5L_iterate1_t' (aka 'int (*)(long, const char *, const H5L_info1_t *, void *)') [-Wincompatible-function-pointer-types]
H5Literate(gid, H5_INDEX_CRT_ORDER, H5_ITER_NATIVE, NULL, fix_dimensions, NULL);
^~~~~~~~~~~~~~
/usr/local/include/H5Lpublic.h:1835:42: note: passing argument to parameter 'op' here
H5L_iterate1_t op, void *op_data);
^
/usr/ports/math/vtk9/work/VTK-9.3.0/ThirdParty/cgns/vtkcgns/src/adfh/ADFH.c:1542:65: error: incompatible function pointer types passing 'herr_t (hid_t, const char *, const H5L_info2_t *, void *)' (aka 'int (long, const char *, const H5L_info2_t *, void *)') to parameter of type 'H5L_iterate1_t' (aka 'int (*)(long, const char *, const H5L_info1_t *, void *)') [-Wincompatible-function-pointer-types]
!H5Literate(hpid, H5_INDEX_CRT_ORDER, H5_ITER_NATIVE, NULL, compare_children, (void *)&stat)) {
^~~~~~~~~~~~~~~~
/usr/local/include/H5Lpublic.h:1835:42: note: passing argument to parameter 'op' here
H5L_iterate1_t op, void *op_data);
```
Version: 9.3.0
clang-16
FreeBSD 14.0https://gitlab.kitware.com/vtk/vtk/-/issues/19207Enable testing ABI Mangling with VTK_ENABLE_KITS2023-12-28T13:08:17-05:00Ryan Krattigerryan.krattiger@kitware.comEnable testing ABI Mangling with VTK_ENABLE_KITSThe ABI Mangling test parse the contents of the compiled binaries for symbols with with non-`"hidden"` visibility and verifies all of these symbols contain the ABI Namespace string.
There are a set of cases where each VTK module will li...The ABI Mangling test parse the contents of the compiled binaries for symbols with with non-`"hidden"` visibility and verifies all of these symbols contain the ABI Namespace string.
There are a set of cases where each VTK module will list EXCEPTIONS to the ABI Namespace. In the case of VTK Kits, multiple modules will be linked into a common binary. When the ABI mangling test is run for each module in the Kit it will not know about exceptions for its module, but the kit binary may also contain exceptionable symbols from other modules in that kit.
The original solution for this was to inspect the `TARGET_OBJECTS` for each module. However, on some platforms the symbol attribute `visibility="hidden"` is not applied until the final library is linked. This leads to false positive results where private symbols that do not require ABI mangling are listed as errors in the test.
A possible solution to this could be to aggregate a list of module `TARGET_FILES`, strip duplicates, and create an ABI mangling test for each of the aggregated files with their appropriate exceptions.
CC: @ben.boeckel @svenevsRyan Krattigerryan.krattiger@kitware.comRyan Krattigerryan.krattiger@kitware.comhttps://gitlab.kitware.com/vtk/vtk/-/issues/19200FindFreetype: port implib FindFreeType.cmake changes from upstream CMake2023-12-19T09:39:10-05:00John ParentFindFreetype: port implib FindFreeType.cmake changes from upstream CMakehttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/8775 Backported https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9973 into CMake. However, https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9973 introduces a bug when consider...https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8775 Backported https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9973 into CMake. However, https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9973 introduces a bug when considering import libraries on Windows. https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8920 makes the required patch on the CMake side. We need to port the changes in https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8920 to VTK to deal with Freetype's import libraries with CMakes older than 3.28.1.
cc @ben.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/19172MinGW compilation issues2023-12-29T14:10:21-05:00Ben BoeckelMinGW compilation issuesWe've had a number of MinGW failures get reported lately:
- #19050
- https://discourse.vtk.org/t/build-vtk9-1-0-error-use-mingw64-in-win10/7076/14
- https://discourse.vtk.org/t/build-vtk9-3-0-msys2-mingw64-on-win10-undefined-reference-...We've had a number of MinGW failures get reported lately:
- #19050
- https://discourse.vtk.org/t/build-vtk9-1-0-error-use-mingw64-in-win10/7076/14
- https://discourse.vtk.org/t/build-vtk9-3-0-msys2-mingw64-on-win10-undefined-reference-to-template/12720
- https://discourse.vtk.org/t/vtk9-3-0-mingw-multiple-definition-of-vtktiff-tiffbuiltincodecs/12723
- https://discourse.vtk.org/t/vtk-9-3-vtk-sln-build-failed/12622
- This patch: https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-vtk/007-dll-export-some-functions.patch
We should at least compile-test MinGW and try to get fixes into 9.3.x.
Cc: @spiros.tsalikisSpiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/vtk/vtk/-/issues/19129Name mangling issue when combining VTK + QT for webasm build (Emscripten) for...2023-10-17T19:35:05-04:00ruell magpayoName mangling issue when combining VTK + QT for webasm build (Emscripten) for FreetypeFollow this steps in the original post including the versions:
https://discourse.vtk.org/t/vtk-qt-in-emscripten-webassembly-opengl-error-unknown-type-name-pfnglpushdebuggroupproc-did-you-mean-pfnglpushdebuggroupkhrproc/12447/8
issue is ...Follow this steps in the original post including the versions:
https://discourse.vtk.org/t/vtk-qt-in-emscripten-webassembly-opengl-error-unknown-type-name-pfnglpushdebuggroupproc-did-you-mean-pfnglpushdebuggroupkhrproc/12447/8
issue is freetype conflict in definitions between QT 6.5.0 and any version of VTK including 9.3.0
```
wasm-ld: error: duplicate symbol: ft_mem_realloc
>>> defined in ../../dependencies/VTK-9.2.6/lib\\libvtkfreetype-9.2.a(ftbase.c.o)
>>> defined in C:/Qt/6.5.0/wasm_singlethread/lib/libQt6BundledFreetype.a(ftbase.c.o)
wasm-ld: error: duplicate symbol: FT_GlyphLoader_CheckPoints
>>> defined in ../../dependencies/VTK-9.2.6/lib\\libvtkfreetype-9.2.a(ftbase.c.o)
>>> defined in C:/Qt/6.5.0/wasm_singlethread/lib/libQt6BundledFreetype.a(ftbase.c.o)
wasm-ld: error: duplicate symbol: FT_GlyphLoader_CheckSubGlyphs
>>> defined in ../../dependencies/VTK-9.2.6/lib\\libvtkfreetype-9.2.a(ftbase.c.o)
>>> defined in C:/Qt/6.5.0/wasm_singlethread/lib/libQt6BundledFreetype.a(ftbase.c.o)
```https://gitlab.kitware.com/vtk/vtk/-/issues/19128Qt + osmesa = broken, but no CMake error?2023-10-11T14:45:01-04:00Matthew WoehlkeQt + osmesa = broken, but no CMake error?I configured VTK with (among other things):
```
-DVTK_BUILD_ALL_MODULES=ON
-DVTK_OPENGL_HAS_OSMESA:BOOL=ON
-DVTK_USE_X:BOOL=OFF
```
I am told that this is broken (note that `-DVTK_BUILD_ALL_MODULES=ON` enables Qt), and that CMake should...I configured VTK with (among other things):
```
-DVTK_BUILD_ALL_MODULES=ON
-DVTK_OPENGL_HAS_OSMESA:BOOL=ON
-DVTK_USE_X:BOOL=OFF
```
I am told that this is broken (note that `-DVTK_BUILD_ALL_MODULES=ON` enables Qt), and that CMake should have complained about it.https://gitlab.kitware.com/vtk/vtk/-/issues/19084Quick CI run support2024-03-21T18:37:24-04:00Ben BoeckelQuick CI run support`Do: test` runs all CI which ends up being very expensive and cause long queue/wait times for results. Instead, offer a mechanism to run just "quick" tests.
# Implementation
## move "quick" jobs to a separate stage (`Do: test -s quick`...`Do: test` runs all CI which ends up being very expensive and cause long queue/wait times for results. Instead, offer a mechanism to run just "quick" tests.
# Implementation
## move "quick" jobs to a separate stage (`Do: test -s quick`)
### Pros
- easy "play" button in the UI as well
### Cons
- need to specify `needs: []` and `dependencies: []` in CI for jobs in the stage after it
## name certain jobs as "quick" (`Do test -n quick`)
### Pros
- localized change
### Cons
- Per-job play interaction in the UI
# Which jobs?
At least one from each platform:
- macos-arm64
- linux "everything"
- windows
Also important in the set:
- static
- kitshttps://gitlab.kitware.com/vtk/vtk/-/issues/19049Use `FORTIFY_SOURCE=3` somewhere on CI2023-08-15T08:11:31-04:00Sean McBrideUse `FORTIFY_SOURCE=3` somewhere on CISince glibc 2.34 and GCC 12, there is a new FORTIFY_SOURCE level (3) that would be nice to have on CI.
You can read more about it here for example:
https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#
@ben.b...Since glibc 2.34 and GCC 12, there is a new FORTIFY_SOURCE level (3) that would be nice to have on CI.
You can read more about it here for example:
https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#
@ben.boeckel is there a bot with new enough glibc / gcc that this could be added to?
(See also #18100.)https://gitlab.kitware.com/vtk/vtk/-/issues/19047Bad module dependency for vtkGenerateTimeSteps2023-08-22T09:22:33-04:00Charly BollingerBad module dependency for vtkGenerateTimeSteps## Description
The useful `vtkGenerateTimeSteps` filter can be found in the `VTK::FiltersHybrid` module. Several sources could need this filter to avoid code duplication, if they wanted the source to allow time steps generation. This is...## Description
The useful `vtkGenerateTimeSteps` filter can be found in the `VTK::FiltersHybrid` module. Several sources could need this filter to avoid code duplication, if they wanted the source to allow time steps generation. This is the case of the `vtkTimeSourceExample` and the more recent `vtkSpatioTemporalHarmonicsSource`.
However, the `VTK::FiltersHybrid` module implies adding strong dependencies, such as the `VTK::RenderingCore` module. This would be bad to need the rendering module to be able to create sources.
## Possible fixes
From the best to the worst solution imo:
* The `vtkGenerateTimeSteps` filter should be moved out of this module, in a better fitting module such as `VTK::FiltersCore` or `VTK::FiltersGeneral`.
* The `VTK::FiltersHybrid` module should move every filter depending on rendering in a more appropriate module, to remove the `VTK::RenderingCore` module dependency.
* Sources needing the `vtkGenerateTimeSteps` filter should be moved in the `VTK::FiltersHybrid` module.https://gitlab.kitware.com/vtk/vtk/-/issues/19046ThirdParty: audit `vtk_module_find_package` calls for `PRIVATE_IF_SHARED` eli...2023-08-08T09:26:05-04:00Ben BoeckelThirdParty: audit `vtk_module_find_package` calls for `PRIVATE_IF_SHARED` eligibilitySee !10393.See !10393.https://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/18978Classes deprecation master issue2024-03-14T11:50:29-04:00Spiros TsalikisClasses deprecation master issueThis is a list of classes to deprecate which are no longer needed and will be deprecated in the future. Please add any classes in the following checklist for it to be considered.
CommonCore:
- [ ] vtkLargeInteger
- [ ] vtkTypedDataArray...This is a list of classes to deprecate which are no longer needed and will be deprecated in the future. Please add any classes in the following checklist for it to be considered.
CommonCore:
- [ ] vtkLargeInteger
- [ ] vtkTypedDataArray: vtkGenericDataArray has made it obsolete
CommonDataModel:
- [ ] vtkStructuredPoints (and related classes): Same thing as vtkImageData
- [ ] vtkUniformGrid (and related classes): It only has AMR related functions which could be moved in vtkUniformGridAMR
- [ ] vtkHierarchicalBoxDataSet (and related classes): vtkOverlappingAMR has made it obsolete
- [ ] vtkMultiBlockDataSet: vtkPartitionedDataSetCollection has made it obsolete
- [ ] vtkMultiPieceDataSet: vtkPartitionedDataSet has made it obsolete
- [ ] vtkCellIterator classes need to be explored
FiltersGeneral:
- [ ] vtkLevelIdScalars: this is just vtkOverlappingAMRLevelIdScalars by another name
- [ ] vtkMultiBlockMergeFilter: vtkMergeBlocks is the new filter.
- [ ] vtkMergeCells: vtkAppendDataSets is the new filter to use.
FiltersHybrid:
- [ ] vtkDSPFilterGroup/vtkDSPFilterDefinition: unmaintained, not used anywhere.
FiltersReebGraph:
- [ ] classes in Filters/ReebGraph
FiltersSMP:
- [ ] classes in Filters/SMP
IOOggTheora:
- [ ] vtkOggTheoraWriter https://gitlab.kitware.com/vtk/vtk/-/merge_requests/10048
ParallelCore:
- [ ] vtkThreadedTaskQueue: replaced by vtkThreadedCallbackQueue
RenderingCore:
- [ ] vtkCompositeDataDisplayAttributesLegacy: replaced by vtkCompositeDataDisplayAttributesSpiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/vtk/vtk/-/issues/18867Python: upgrade to match modern practices2023-10-13T13:04:54-04:00Ben BoeckelPython: upgrade to match modern practicesMuch needs to be done for abi3 builds to really work.
WrappingPythonCore:
- store internal `PyTypeObject*` heap types on the `vtkCommonCore` module itself
- convert basic types to heap types (this will also simplify multiple inheritanc...Much needs to be done for abi3 builds to really work.
WrappingPythonCore:
- store internal `PyTypeObject*` heap types on the `vtkCommonCore` module itself
- convert basic types to heap types (this will also simplify multiple inheritance, which is impractical for static types)
As for the generated code:
Porting types:
- the `Py_TPFLAGS_IMMUTABLETYPE` flag is implicit in static types, so we'll need to pay attention and add it where needed
- getting access to base type pointers will need some work as they'll be stored in module state of other modules
- may be able to just do `PyObject_GetAttrString(depmod, "baseclass")` or something to get the `PyTypeObject*` we need
Porting modules:
- move to multi-phase initialization (PEP 489)
- store module state on the modules themselves (PEP 573)
- caches and whatnot should also be stored on the relevant modules (though probably just `vtkCommonCore`?) (PEP 630)
Landmark Python versions:
- 3.9 introduced `sometype.__module__` which gets access to the module object and therefore the state.
- 3.9 introduced `PyCMethod` which gives the defining class `PyTypeObject*` to methods (to more easily access the state)
- See [this feature request](https://discuss.python.org/t/support-defining-class-argument-to-other-method-signatures/25474) for making it more accessible; 3.13 at the earliest
- 3.10 allows `PyType_GetSlot` on static types
- 3.11 puts the buffer API into the stable ABI
Relevant PEPs:
- [PEP 384: Defining a Stable ABI](https://peps.python.org/pep-0384/)
- [PEP 489: Multi-phase extension module initialization](https://peps.python.org/pep-0489/)
- [PEP 573: Module State Access from C Extension Methods](https://peps.python.org/pep-0573/)
- [PEP 630: Isolating Extension Modules](https://peps.python.org/pep-0630/)
Other links:
- https://github.com/markshannon/New-C-API-for-Python
- Scrapping the C API and writing a C bindings generator and then using `cffi` on that
Cc: @dgobbi @banesullivanhttps://gitlab.kitware.com/vtk/vtk/-/issues/18819Raytracing module does not link with GCC 4.8.52023-03-01T10:51:51-05:00Mathieu Westphal (Kitware)Raytracing module does not link with GCC 4.8.5RenderingRaytracing module does not link correctly with GCC 4.8.5, it fails with the following error (reproduced in ParaView):
```shell
[ 96%] Building CXX object Clients/CommandLineExecutables/CMakeFiles/pvbatch.dir/pvbatch.cxx.o
build...RenderingRaytracing module does not link correctly with GCC 4.8.5, it fails with the following error (reproduced in ParaView):
```shell
[ 96%] Building CXX object Clients/CommandLineExecutables/CMakeFiles/pvbatch.dir/pvbatch.cxx.o
build/lib/libvtkRenderingRayTracing-pv5.11.so.1: undefined reference to `__cpu_indicator_init'
build/lib/libvtkRenderingRayTracing-pv5.11.so.1: undefined reference to `__cpu_model'
collect2: error: ld returned 1 exit status
Clients/CommandLineExecutables/CMakeFiles/pvdataserver.dir/build.make:108: recipe for target 'bin/pvdataserver' failed
make[2]: *** [bin/pvdataserver] Error 1
CMakeFiles/Makefile2:43826: recipe for target 'Clients/CommandLineExecutables/CMakeFiles/pvdataserver.dir/all' failed
make[1]: *** [Clients/CommandLineExecutables/CMakeFiles/pvdataserver.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 96%] Building CXX object CMakeFiles/vtkRemotingViewsPython.dir/CMakeFiles/vtkRemotingViewsPython/vtkSMPVRepresentationProxyPython.cxx.o
build/lib/libvtkRenderingRayTracing-pv5.11.so.1: undefined reference to `__cpu_indicator_init'
build/lib/libvtkRenderingRayTracing-pv5.11.so.1: undefined reference to `__cpu_model'
collect2: error: ld returned 1 exit status
Clients/CommandLineExecutables/CMakeFiles/pvrenderserver.dir/build.make:108: recipe for target 'bin/pvrenderserver' failed
make[2]: *** [bin/pvrenderserver] Error 1
```
works fine in GCC7https://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/18772Python package for Linux ARM64 is missing2023-10-09T19:37:47-04:00dazzag24Python package for Linux ARM64 is missingHi,
I notice that while there is now support for MacosX on ARM64 (e.g M1 chipset) that there is no support for Linux on ARM64.
https://pypi.org/project/vtk/#files
Could this be added?
ThanksHi,
I notice that while there is now support for MacosX on ARM64 (e.g M1 chipset) that there is no support for Linux on ARM64.
https://pypi.org/project/vtk/#files
Could this be added?
Thankshttps://gitlab.kitware.com/vtk/vtk/-/issues/18750vtk wheel: vendored proj does not work because the database is not included2022-12-16T19:22:02-05:00Ben Boeckelvtk wheel: vendored proj does not work because the database is not includedSo VTK's wheels contain `libproj` but not in a way that works because its `proj.db` is not in the wheel itself. Alas, Python packaging intersecting VTK's build system is a nightmare and I was able to get it into the wheel by abusing Pyth...So VTK's wheels contain `libproj` but not in a way that works because its `proj.db` is not in the wheel itself. Alas, Python packaging intersecting VTK's build system is a nightmare and I was able to get it into the wheel by abusing Python's duck typing and just path-traversing in `package_data`, but not in a way that `pip install` liked on install (why does `bdist_wheel` not error on the creation side? who knows):
```
ERROR: For req: vtk==9.2.20221216.dev0. Unknown scheme key used in /home/boeckb/misc/builds/vtk/build-whl/dist/vtk-9.2.20221216.dev0-cp311-cp311-linux_x86_64.whl: share (for file 'vtk-9.2.20221216.data/share/vtk/proj/proj.db'). .data directory contents should be in subdirectories named with a valid scheme key (data, headers, platlib, purelib, scripts)
```
So the wheel build needs to update how the database is placed into the build tree in `ThirdParty/libproj/vtklibproj/data/CMakeLists.txt` and get it into the wheel with whatever `setuptools` wants in `CMake/setup.py.in`.
Cc: @jcfr @banesullivan @dgobbi @danlipsa