VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2018-10-23T12:52:27-04:00https://gitlab.kitware.com/vtk/vtk/-/issues/17085cmake in find-package mode fails to find vtk2018-10-23T12:52:27-04:00Francis Giraldeaucmake in find-package mode fails to find vtkCMake can be used in pkg-config mode to output libs and cflags for VTK. The VTK library is found if used in CMakeLists.txt. However, the find-package mode fails:
```
$ cmake --find-package -DNAME=VTK -DLANGUAGE=CXX -DCOMPILER_ID=GNU -DM...CMake can be used in pkg-config mode to output libs and cflags for VTK. The VTK library is found if used in CMakeLists.txt. However, the find-package mode fails:
```
$ cmake --find-package -DNAME=VTK -DLANGUAGE=CXX -DCOMPILER_ID=GNU -DMODE=COMPILE
CMake Error at /work/software/x86_64/vtk/vtk-8.0.0/lib/cmake/vtk-8.0/VTKConfig.cmake:33 (message):
GCC 4.6 or later is required.
Call Stack (most recent call first):
/mnt/md127/work/software/x86_64/cmake/cmake-3.5.2/share/cmake-3.5/Modules/CMakeFindPackageMode.cmake:190 (find_package)
VTK not found.
CMake Error: Problem processing arguments. Aborting.
```
Inside `VTKConfig.cmake`, the following code returns the error:
```
if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU" AND
CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.6)
message(FATAL_ERROR "GCC 4.6 or later is required." )
endif ()
```
The compiler version is correct (gcc 4.8.5), but the variable `CMAKE_CXX_COMPILER_VERSION` is actually not defined. When passing the additional arguments `-DCMAKE_CXX_COMPILER_VERSION=4.8.5 -DCMAKE_CXX_STANDARD_COMPUTED_DEFAULT=4.8.5`, cmake returns correctly.8.2.0https://gitlab.kitware.com/vtk/vtk/-/issues/17017Feature request: sudo make uninstall2019-12-11T20:03:16-05:00Jason JuangFeature request: sudo make uninstallCurrently after cloning VTK and building it and installing it into the system path `/usr/local/`, there is no easy way to uninstall it. This is problematic because it is very inconvenient if I want to test out different install versions ...Currently after cloning VTK and building it and installing it into the system path `/usr/local/`, there is no easy way to uninstall it. This is problematic because it is very inconvenient if I want to test out different install versions of VTK, I will have to delete the installed library manually.
Could you follow https://cmake.org/Wiki/CMake_FAQ#Can_I_do_.22make_uninstall.22_with_CMake.3F and add in that capability? This will shorten the dev time for whoever uses VTK significantly.8.2.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17893[VTK 9.0] Common/DataModel/vtkCompositeDataSetNodeReference.h not getting ins...2020-05-14T09:56:51-04:00Alexander Neumann[VTK 9.0] Common/DataModel/vtkCompositeDataSetNodeReference.h not getting installedRequired by `vtkDataObjectTreeRange.h` which gets installed. Discovered by building Paraview 5.8 with external VTKRequired by `vtkDataObjectTreeRange.h` which gets installed. Discovered by building Paraview 5.8 with external VTK9.0.1Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17889Inconsistent licenses install location2020-05-11T13:16:48-04:00Orion PoplawskiInconsistent licenses install locationVarious VTK module licenses are installed to /usr/share/licenses/VTK/<MODULE>, but the main VTK license is installed into /usr/share/doc/VTK. Also, module licenses install into "VTK" via CMAKE_PROJECT_NAME:
```
set(_vtk_build_LICENS...Various VTK module licenses are installed to /usr/share/licenses/VTK/<MODULE>, but the main VTK license is installed into /usr/share/doc/VTK. Also, module licenses install into "VTK" via CMAKE_PROJECT_NAME:
```
set(_vtk_build_LICENSE_DESTINATION "${CMAKE_INSTALL_DATAROOTDIR}/licenses/${CMAKE_PROJECT_NAME}")
```
but on Fedora the vtk rpm is named "vtk" and so the files would be better located in /usr/share/licenses/vtk. But I'm pretty sure we don't want to be messing with CMAKE_PROJECT_NAME.9.0.1Ben BoeckelBen Boeckelhttps://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/17695bring back pypi wheels2020-06-16T09:09:55-04:00David E. DeMarlebring back pypi wheelsIn VTK 8.0 and 8.1, we built PyPi wheels for VTK via https://github.com/KitwareMedical/VTKPythonPackage.
8.2 broke the process. For 9.0 we should leverage the new CMake script infrastructure and set of automated tests to bring them back ...In VTK 8.0 and 8.1, we built PyPi wheels for VTK via https://github.com/KitwareMedical/VTKPythonPackage.
8.2 broke the process. For 9.0 we should leverage the new CMake script infrastructure and set of automated tests to bring them back sustainably.9.0.1T.J. CoronaT.J. Coronahttps://gitlab.kitware.com/vtk/vtk/-/issues/18343Config failure for python static build2021-10-28T18:10:25-04:00David GobbiConfig failure for python static buildOn ubuntu 20.04, the following config gives an error for the current release head:
```bash
cmake -G Ninja ../vtk-gitlab -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF \
-DVTK_BUILD_TESTING=OFF -DVTK_PYTHON_VERSION=3 -DVTK_WRAP...On ubuntu 20.04, the following config gives an error for the current release head:
```bash
cmake -G Ninja ../vtk-gitlab -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF \
-DVTK_BUILD_TESTING=OFF -DVTK_PYTHON_VERSION=3 -DVTK_WRAP_PYTHON=ON
```
```text
CMake Error at CMake/vtkModuleWrapPython.cmake:987 (target_link_libraries):
INTERFACE library can only be used with the INTERFACE keyword of
target_link_libraries
```
The cmake code in question:
```cmake
if (_vtk_python_UTILITY_TARGET)
target_link_libraries("${_vtk_python_TARGET_NAME}"
PRIVATE
"${_vtk_python_UTILITY_TARGET}")
endif ()
```
Tested with cmake 3.16.3 and with 3.21, both produced the same error.9.1Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18299vtk-config do not export vtkOpenGLOptions variables2022-07-26T12:18:02-04:00Paul Lafoixvtk-config do not export vtkOpenGLOptions variablesWhen using an external vtk, the variables VTK_CAN_DO_ONSCREEN or VTK_DEFAULT_RENDER_WINDOW_OFFSCREEN are not exportedWhen using an external vtk, the variables VTK_CAN_DO_ONSCREEN or VTK_DEFAULT_RENDER_WINDOW_OFFSCREEN are not exported9.1https://gitlab.kitware.com/vtk/vtk/-/issues/17896Follow-up from "FindLibHaru, FindFreeType: handle multi-config library variab...2020-05-13T16:33:44-04:00Ben BoeckelFollow-up from "FindLibHaru, FindFreeType: handle multi-config library variables"The following discussion from !6890 should be addressed:
- [ ] @Neumann-A started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/6890#note_756249): (+9 comments)
> @ben.boeckel: I think you need to change `vtk_...The following discussion from !6890 should be addressed:
- [ ] @Neumann-A started a [discussion](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/6890#note_756249): (+9 comments)
> @ben.boeckel: I think you need to change `vtk_detect_library_type` because it is fair game to pass any of those variables via the cmake command line and skip the find_library call in any FindModule.cmake9.1https://gitlab.kitware.com/vtk/vtk/-/issues/17515Fails to find PTHREAD_MUTEX_RECURSIVE on FreeBSD2020-05-16T19:06:58-04:00yurivictFails to find PTHREAD_MUTEX_RECURSIVE on FreeBSDThis line fails:
```
CHECK_SYMBOL_EXISTS(PTHREAD_MUTEX_RECURSIVE pthread.h HAVE_PTHREAD_MUTEX_RECURSIVE_DEFN)
```
Log:
```
Determining if the PTHREAD_MUTEX_RECURSIVE exist failed with the following output:
Change Dir: /tmp/x/CMakeFiles/...This line fails:
```
CHECK_SYMBOL_EXISTS(PTHREAD_MUTEX_RECURSIVE pthread.h HAVE_PTHREAD_MUTEX_RECURSIVE_DEFN)
```
Log:
```
Determining if the PTHREAD_MUTEX_RECURSIVE exist failed with the following output:
Change Dir: /tmp/x/CMakeFiles/CMakeTmp
Run Build Command:"/usr/local/bin/gmake" "cmTC_d1e0e/fast"
/usr/local/bin/gmake -f CMakeFiles/cmTC_d1e0e.dir/build.make CMakeFiles/cmTC_d1e0e.dir/build
gmake[1]: Entering directory '/tmp/x/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_d1e0e.dir/CheckSymbolExists.c.o
/usr/bin/cc -o CMakeFiles/cmTC_d1e0e.dir/CheckSymbolExists.c.o -c /tmp/x/CMakeFiles/CMakeTmp/CheckSymbolExists.c
/tmp/x/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:18: error: cannot take the address of an rvalue of type 'int'
return ((int*)(&PTHREAD_MUTEX_RECURSIVE))[argc];
^~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
```9.1Sean McBrideSean McBridehttps://gitlab.kitware.com/vtk/vtk/-/issues/18576Fails to build with NetCDF 4.9.02022-07-07T21:03:17-04:00Bas CouwenbergFails to build with NetCDF 4.9.0As reported in [Debian Bug #1012703](https://bugs.debian.org/1012703), VTK fails to build with NetCDF 4.9.0:
```
In file included from /<<PKGBUILDDIR>>/debian/build/ThirdParty/netcdf/vtk_netcdf.h:22,
from /<<PKGBUILDDIR>...As reported in [Debian Bug #1012703](https://bugs.debian.org/1012703), VTK fails to build with NetCDF 4.9.0:
```
In file included from /<<PKGBUILDDIR>>/debian/build/ThirdParty/netcdf/vtk_netcdf.h:22,
from /<<PKGBUILDDIR>>/ThirdParty/exodusII/vtkexodusII/include/exodusII.h:22,
from /<<PKGBUILDDIR>>/ThirdParty/exodusII/vtkexodusII/src/ex_utils.c:20:
/<<PKGBUILDDIR>>/ThirdParty/exodusII/vtkexodusII/src/ex_utils.c: In function ‘vtkexodusII_ex__compress_variable’:
/<<PKGBUILDDIR>>/ThirdParty/exodusII/vtkexodusII/src/ex_utils.c:1773:19: error: expected identifier or ‘(’ before numeric constant
1773 | const int NC_SZIP_NN = 32; /* Selects nearest neighbor coding method for szip. */
| ^~~~~~~~~~
```
`netcdf.h` was updated in 4.9.0 to include:
```C
#define NC_SZIP_NN 32 /**< SZIP NN option mask. */
```
One solution to this conflict is renaming the variable, as done in this patch: [netcdf-4.9.0.patch](/uploads/a56d692dbc148ca790f9f9f2a897cc0a/netcdf-4.9.0.patch)9.2Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18512vtk_module_compile_options does not behave exactly like target_compile_options2022-04-15T21:03:12-04:00Mathieu Westphal (Kitware)vtk_module_compile_options does not behave exactly like target_compile_options`vtk_module_compile_options(target PUBLIC PRIVATE)` fails with:
```
target_compile_options called with incorrect number of arguments
```
While
target_compile_options(target PUBLIC PRIVATE) works without issue.
The problem is that ...`vtk_module_compile_options(target PUBLIC PRIVATE)` fails with:
```
target_compile_options called with incorrect number of arguments
```
While
target_compile_options(target PUBLIC PRIVATE) works without issue.
The problem is that during the argument processing in vtk_module_compile_options, if none are provided, the resulting call is:
`target_compile_options(target)`, which is incorrect.
This is highly impractical with these kind of codes:
```
vtk_module_compile_options(target PUBLIC ${ACCUMULATED_PUBLIC_OPTIONS} PRIVATE ${ACCUMULATED_PRIVATE_OPTIONS} )
```
@ben.boeckel9.2Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18506VTKDetermineVersion.cmake bug2022-07-25T16:39:30-04:00olesenVTKDetermineVersion.cmake bugCompiling a git version of paraview with the various submodules.
VTKDetermineVersion.cmake (Line 64) reports that it detected a VTK git version v5.10.1-884-gefeaf2c2c5 but has a hardcoded version of 9.1.xyz.
It appears to be running _g...Compiling a git version of paraview with the various submodules.
VTKDetermineVersion.cmake (Line 64) reports that it detected a VTK git version v5.10.1-884-gefeaf2c2c5 but has a hardcoded version of 9.1.xyz.
It appears to be running _git describe_ from one directory below where it should be.9.2Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/19214vendored mpi4py needs to be re-Cythonized in order to build with Python 3.122024-01-02T11:07:56-05:00Ben Wibkingvendored mpi4py needs to be re-Cythonized in order to build with Python 3.12VTK does not build with Python 3.12 due to its use of removed CPython APIs within the Cython-generated code for mpi4py.
See for example: https://github.com/cython/cython/issues/4788. (There are other issues with Python 3.12 as well.)
T...VTK does not build with Python 3.12 due to its use of removed CPython APIs within the Cython-generated code for mpi4py.
See for example: https://github.com/cython/cython/issues/4788. (There are other issues with Python 3.12 as well.)
The fixes are in the latest version of Cython, but the source code for mpi4py included here (https://gitlab.kitware.com/vtk/vtk/-/tree/master/ThirdParty/mpi4py) needs to be re-generated so that it can build with Python 3.12.
This patch will fix the issues and allow it to build, but it should only be used as a temporary workaround: https://github.com/openPMD/openPMD-api/files/13773304/fix-mpi4py-cython-python3.12.patch9.3Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/19208Underlinking of libvtkRenderingLICOpenGL2Java.so2024-01-02T13:18:10-05:00StefanBruensUnderlinking of libvtkRenderingLICOpenGL2Java.soWith the change from vtkCompositePolyDataMapper2 to vtkCompositePolyDataMapper
https://gitlab.kitware.com/vtk/vtk/-/commit/5b159e6fb88ca19346a5a8465b80f7379dea3d7d
`VTK::RenderingLICOpenGL2` became dependent of `VTK::RenderingCore` (...With the change from vtkCompositePolyDataMapper2 to vtkCompositePolyDataMapper
https://gitlab.kitware.com/vtk/vtk/-/commit/5b159e6fb88ca19346a5a8465b80f7379dea3d7d
`VTK::RenderingLICOpenGL2` became dependent of `VTK::RenderingCore` (...Mapper2 is in RenderingOpenGL2, ...Mapper is in RenderingCore).
For the regular shared lib this is fine, as the module has a private dep on RenderingCore, but the Java wrapper needs this as a public dependency, otherwise the RenderingCore Java wrapper library is omitted; the build fails when "--no-undefined" is used (otherwise, this likely will result in a linker error at runtime).
```
[ 4106s] [ 95%] Linking CXX shared library ../../lib64/java/vtk-Linux-x86_64/libvtkRenderingLICOpenGL2Java.so
[ 4106s] cd /home/abuild/rpmbuild/BUILD/VTK-9.3.0/build/Wrapping/Java && /usr/bin/cmake -E cmake_link_script CMakeFiles/vtkRenderingLICOpenGL2Java.dir/link.txt --verbose=1
[ 4106s] /usr/bin/g++ -fPIC -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -DNDEBUG -O2 -g -DNDEBUG -Wl,-lc -Wl,--as-needed -Wl,--no-undefined -Wl,-z,now -shared -Wl,-soname,libvtkRenderingLICOpenGL2Java.so -o ../../lib64/java/vtk-Linux-x86_64/libvtkRenderingLICOpenGL2Java.so CMakeFiles/vtkRenderingLICOpenGL2Java.dir/CMakeFiles/vtkRenderingLICOpenGL2Java/vtkPainterCommunicatorJava.cxx.o CMakeFiles/vtkRenderingLICOpenGL2Java.dir/CMakeFiles/vtkRenderingLICOpenGL2Java/vtkBatchedSurfaceLICMapperJava.cxx.o CMakeFiles/vtkRenderingLICOpenGL2Java.dir/CMakeFiles/vtkRenderingLICOpenGL2Java/vtkCompositeSurfaceLICMapperJava.cxx.o CMakeFiles/vtkRenderingLICOpenGL2Java.dir/CMakeFiles/vtkRenderingLICOpenGL2Java/vtkCompositeSurfaceLICMapperDelegatorJava.cxx.o CMakeFiles/vtkRenderingLICOpenGL2Java.dir/CMakeFiles/vtkRenderingLICOpenGL2Java/vtkImageDataLIC2DJava.cxx.o CMakeFiles/vtkRenderingLICOpenGL2Java.dir/CMakeFiles/vtkRenderingLICOpenGL2Java/vtkLineIntegralConvolution2DJava.cxx.o CMakeFiles/vtkRenderingLICOpenGL2Java.dir/CMakeFiles/vtkRenderingLICOpenGL2Java/vtkStructuredGridLIC2DJava.cxx.o CMakeFiles/vtkRenderingLICOpenGL2Java.dir/CMakeFiles/vtkRenderingLICOpenGL2Java/vtkSurfaceLICCompositeJava.cxx.o CMakeFiles/vtkRenderingLICOpenGL2Java.dir/CMakeFiles/vtkRenderingLICOpenGL2Java/vtkSurfaceLICInterfaceJava.cxx.o CMakeFiles/vtkRenderingLICOpenGL2Java.dir/CMakeFiles/vtkRenderingLICOpenGL2Java/vtkSurfaceLICMapperJava.cxx.o CMakeFiles/vtkRenderingLICOpenGL2Java.dir/CMakeFiles/vtkRenderingLICOpenGL2Java/vtkTextureIOJava.cxx.o CMakeFiles/vtkRenderingLICOpenGL2Java.dir/CMakeFiles/vtkRenderingLICOpenGL2Java/vtkRenderingLICOpenGL2ModuleJava.cxx.o -Wl,-rpath,"\$ORIGIN/../../:\$ORIGIN:/usr/lib64/jvm/java/lib:/usr/lib64/jvm/java/lib/server" ../../lib64/libvtkRenderingLICOpenGL2.so.9.3 ../../lib64/java/vtk-Linux-x86_64/libvtkRenderingOpenGL2Java.so ../../lib64/libvtkRenderingOpenGL2.so.9.3 /usr/lib64/libGLEW.so /usr/lib64/libX11.so ../../lib64/libvtkIOImage.so.9.3 ../../lib64/libvtkRenderingHyperTreeGrid.so.9.3 ../../lib64/libvtkImagingCore.so.9.3 ../../lib64/libvtkRenderingUI.so.9.3 /usr/lib64/libX11.so ../../lib64/libvtkRenderingCore.so.9.3 ../../lib64/libvtkFiltersGeneral.so.9.3 ../../lib64/java/vtk-Linux-x86_64/libvtkCommonExecutionModelJava.so ../../lib64/java/vtk-Linux-x86_64/libvtkCommonDataModelJava.so ../../lib64/libvtkFiltersCore.so.9.3 ../../lib64/libvtkCommonExecutionModel.so.9.3 ../../lib64/libvtkCommonDataModel.so.9.3 ../../lib64/libvtkCommonTransforms.so.9.3 ../../lib64/libvtkCommonMisc.so.9.3 ../../lib64/java/vtk-Linux-x86_64/libvtkCommonCoreJava.so ../../lib64/libvtkJava.so.9.3 /usr/lib64/jvm/java/lib/libjawt.so /usr/lib64/jvm/java/lib/server/libjvm.so ../../lib64/libvtkCommonMath.so.9.3 ../../lib64/libvtkCommonCore.so.9.3 ../../lib64/libvtksys.so.9.3 -ldl -lpthread ../../lib64/libvtkkissfft.so.9.3 -Wl,-rpath-link,/home/abuild/rpmbuild/BUILD/VTK-9.3.0/build/lib64:/home/abuild/rpmbuild/BUILD/VTK-9.3.0/build/lib64/java/vtk-Linux-x86_64
[ 4106s] /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/vtkRenderingLICOpenGL2Java.dir/CMakeFiles/vtkRenderingLICOpenGL2Java/vtkCompositeSurfaceLICMapperJava.cxx.o: in function `vtkCompositeSurfaceLICMapper_Typecast':
[ 4106s] /home/abuild/rpmbuild/BUILD/VTK-9.3.0/build/Wrapping/Java/CMakeFiles/vtkRenderingLICOpenGL2Java/vtkCompositeSurfaceLICMapperJava.cxx:18: undefined reference to `vtkCompositePolyDataMapper_Typecast'
[ 4106s] collect2: error: ld returned 1 exit status
[ 4106s] make[2]: *** [Wrapping/Java/CMakeFiles/vtkRenderingLICOpenGL2Java.dir/build.make:387: lib64/java/vtk-Linux-x86_64/libvtkRenderingLICOpenGL2Java.so] Error 1
```
Moving `VTK::RenderingCore` from `PRIVATE_DEPENDS` to `DEPENDS` in the `vtk.module` fixes this.9.3Ben 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/18624Update diy2 ti fix build errors.2023-08-17T16:15:22-04:00Alexander NeumannUpdate diy2 ti fix build errors.diy dropped small vector form choco to itlib.
Reason:
choco small vector won't compile with C++20 (and I currently see those errors.)diy dropped small vector form choco to itlib.
Reason:
choco small vector won't compile with C++20 (and I currently see those errors.)9.3Ben BoeckelBen Boeckelhttps://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/17816VTK Wheel not working in Python3.82020-04-02T15:01:13-04:00ThiagoVTK Wheel not working in Python3.8Hi,
I've downloaded the VTK using git. I have the last commit (118d20aacadff5e3bba489d1ebb422f7858c72ca). I'm configuring and generating the Wheel this way:
```
cmake -GNinja -DVTK_BUILD_DOCUMENTATION=OFF -DVTK_BUILD_EXAMPLES=OFF -DBUI...Hi,
I've downloaded the VTK using git. I have the last commit (118d20aacadff5e3bba489d1ebb422f7858c72ca). I'm configuring and generating the Wheel this way:
```
cmake -GNinja -DVTK_BUILD_DOCUMENTATION=OFF -DVTK_BUILD_EXAMPLES=OFF -DBUILD_SHARED_LIBS=ON -DOpenGL_GL_PREFERENCE=GLVND -DVTK_USE_TK=OFF -DVTK_WRAP_JAVA=OFF -DVTK_WRAP_PYTHON=ON -DVTK_PYTHON_VERSION:STRING=3 -DVTK_WHEEL_BUILD=ON -DVTK_WRAP_TCL=OFF -DVTK_USE_CUDA=ON -DCMAKE_BUILD_TYPE=Release ../vtk/
ninja
python3 setup.py bdist_wheel
pip3 install ./dist/vtk-9.0.0-cp38-cp38-linux_x86_64.whl
```
I'm installing the wheel inside a virtualenv. When I try to import vtk that error that happens:
```
$ python
Python 3.8.2 (default, Mar 13 2020, 10:14:16)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import vtk
Traceback (most recent call last):
File "/home/thiago/.virtualenvs/vtk90/lib/python3.8/site-packages/vtkmodules/__init__.py", line 13, in <module>
from . import vtkCommonCore
ImportError: cannot import name 'vtkCommonCore' from partially initialized module 'vtkmodules' (most likely due to a circular import) (/home/thiago/.virtualenvs/vtk90/lib/python3.8/site-packages/vtkmodules/__init__.py)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/thiago/.virtualenvs/vtk90/lib/python3.8/site-packages/vtk.py", line 30, in <module>
all_m = importlib.import_module('vtkmodules.all')
File "/home/thiago/.virtualenvs/vtk90/lib/python3.8/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "/home/thiago/.virtualenvs/vtk90/lib/python3.8/site-packages/vtkmodules/__init__.py", line 15, in <module>
import _vtkmodules_static
ModuleNotFoundError: No module named '_vtkmodules_static
```9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17811FindNetCDF.cmake creates an unusable namespaced library2020-03-25T21:03:11-04:00Kyle BentleyFindNetCDF.cmake creates an unusable namespaced libraryI am using the CMake module for NetCDF in a different project, and I found what may be a small oversight in the CMake section of the NetCDF module provided by VTK.
Colleagues and myself were noticing that with the new release of netCDF,...I am using the CMake module for NetCDF in a different project, and I found what may be a small oversight in the CMake section of the NetCDF module provided by VTK.
Colleagues and myself were noticing that with the new release of netCDF, 4.7.3, that the namespaced version of the library, NetCDF::NetCDF, caused linking errors. It took us a moment to realize that while that imported target has the correct library name - netCDF, it doesn't provide any path information. This caused a situation where our build would find the locally compiled netCDF library, by name, but at link time would find an older system library in /usr/lib that didn't have the newer symbols. This happened even when using target_link_directories explicitly. When we hardcode the path to the correct library, all works as expected.
We were able to temporarily work around the issue by using the exported target netCDF_LIB_DIR from the lib/cmake/*config, and altering the target properties on the namespace to be SHARED instead of INTERFACE, and providing an IMPORTED_LOCATION based on the libname, and the netCDF_LIB_DIR above. The code below shows the changes we made (roughly). Is this an appropriate approach? I'm fairly well-versed in CMake, but I feel as if I'm missing something, or that it's not quite working as intended, compared to similarly namespaced targets. It'll work for us, on a single machine, but otherwise it goes against the 'create relocatable package' guidelines from CMake.
Any advice? Is there a way to get the path information using the Module as-is? Thanks in advance.
Old Section of code
```
# Try to find a CMake-built NetCDF.
find_package(netCDF CONFIG QUIET)
if (netCDF_FOUND)
# Forward the variables in a consistent way.
set(NetCDF_FOUND "${netCDF_FOUND}")
set(NetCDF_INCLUDE_DIRS "${netCDF_INCLUDE_DIR}")
set(NetCDF_LIBRARIES "${netCDF_LIBRARIES}")
set(NetCDF_VERSION "${NetCDFVersion}")
if (NOT TARGET NetCDF::NetCDF)
add_library(NetCDF::NetCDF INTERFACE IMPORTED)
set_target_properties(NetCDF::NetCDF PROPERTIES
INTERFACE_LINK_LIBRARIES "${NetCDF_LIBRARIES}")
endif ()
# Skip the rest of the logic in this file.
return ()
endif ()
```
New section of code
```
# Try to find a CMake-built NetCDF.
find_package(netCDF CONFIG QUIET)
if (netCDF_FOUND)
# Forward the variables in a consistent way.
set(NetCDF_FOUND "${netCDF_FOUND}")
set(NetCDF_INCLUDE_DIRS "${netCDF_INCLUDE_DIR}")
set(NetCDF_LIBRARIES "${netCDF_LIBRARIES}")
set(NetCDF_VERSION "${NetCDFVersion}")
set(NetCDF_LIBRARY_DIR "${netCDF_LIB_DIR}") <------------------- New
if (NOT TARGET NetCDF::NetCDF)
add_library(NetCDF::NetCDF SHARED IMPORTED) <------------------- Changed
set_target_properties(NetCDF::NetCDF PROPERTIES <------------------- Changed
IMPORTED_LOCATION "${NetCDF_LIBRARY_DIR}"/lib"${NetCDF_LIBRARIES}".so)
endif ()
# Skip the rest of the logic in this file.
return ()
endif ()
```9.0Ben BoeckelBen Boeckel