VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2020-05-14T09:56:51-04:00https://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/17895[VTK 9.0] Find(LibHaru|LZMA).cmake cannot correctly handle finding both DEBUG...2020-05-14T09:56:05-04:00Alexander Neumann[VTK 9.0] Find(LibHaru|LZMA).cmake cannot correctly handle finding both DEBUG and RELEASE librariesError:
```
-- Found LibHaru: optimized;D:/para/installed/x64-windows/lib/libhpdf.lib;debug;D:/para/installed/x64-windows/debug/lib/libhpdfd.lib (found suitable version "2.4.0-dev", minimum required is "2.4.0")
CMake Error at CMake/vtkDe...Error:
```
-- Found LibHaru: optimized;D:/para/installed/x64-windows/lib/libhpdf.lib;debug;D:/para/installed/x64-windows/debug/lib/libhpdfd.lib (found suitable version "2.4.0-dev", minimum required is "2.4.0")
CMake Error at CMake/vtkDetectLibraryType.cmake:31 (message):
Unparsed arguments for vtk_detect_library_type:
D:/para/installed/x64-windows/lib/libhpdf.lib;debug;D:/para/installed/x64-windows/debug/lib/libhpdfd.lib
Call Stack (most recent call first):
CMake/FindLibHaru.cmake:48 (vtk_detect_library_type)
D:/para/scripts/buildsystems/vcpkg.cmake:329 (_find_package)
CMake/vtkModule.cmake:4134 (find_package)
CMake/vtkModule.cmake:4690 (vtk_module_find_package)
CMake/vtkModule.cmake:4564 (vtk_module_third_party_external)
ThirdParty/libharu/CMakeLists.txt:1 (vtk_module_third_party)
```Ben 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/17753libproj >= 62020-04-29T09:26:41-04:00Nico Schlömerlibproj >= 6While VTK itself ships libproj 4.9.3, it's compatible with versions 5.* as well. It's _not_ compatible with version 6.* though. There should probably be a test in `CMake/FindLibPROJ.cmake`.While VTK itself ships libproj 4.9.3, it's compatible with versions 5.* as well. It's _not_ compatible with version 6.* though. There should probably be a test in `CMake/FindLibPROJ.cmake`.https://gitlab.kitware.com/vtk/vtk/-/issues/17868Compile error 9.0RC3, VS 2017, Windows 10, snprintf2020-04-28T00:27:47-04:00Kathleen BiagasCompile error 9.0RC3, VS 2017, Windows 10, snprintfI am using CMake 3.12.2, VS 2017 15.9.22 on a Windows 10 machine.
When I compile, I get errors in libxml2 and tiff:
```
Macro redefinition of 'snprintf' conflicts with Standard Library definition.
```
I have traced it to ThirdParty/libxm...I am using CMake 3.12.2, VS 2017 15.9.22 on a Windows 10 machine.
When I compile, I get errors in libxml2 and tiff:
```
Macro redefinition of 'snprintf' conflicts with Standard Library definition.
```
I have traced it to ThirdParty/libxml2/vtklibxml/CMakeLists.txt, which calls
```
check_sybmol_exists(snprintf "${LIBXML_INCLUDES}" HAVE_SNPRINTF)
```
However, LIBXML_INCLUDES does not list stdio.h which is where snprint is defined, so HAVE_SNPRINTF is set to false.
when ThirdParty/tiff/vtktiff/CMakeLists also checks for snprintf with its call to
```
check_symbol_exists(snprintf "stdio.h" HAVE_SNPRINTF)
```
which should succeed, it doesn’t, because HAVE_SNPRINTF has already been set.
There is a build path where the check for ‘snprintf’ happens before libxml’s check, then things work.
I think that is when vtkhdf5 is included in the build. For my use case, I am not using vtkhdf5.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/16805VTK_JAVA_INSTALL should also create include, bin and lib in the installation ...2020-04-14T09:38:59-04:00Kitware RobotVTK_JAVA_INSTALL should also create include, bin and lib in the installation folder**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=16805). Further discussion may take place here.**
---
If you select VTK_JAVA_INSTALL only the dlls are copied to the destination fold...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=16805). Further discussion may take place here.**
---
If you select VTK_JAVA_INSTALL only the dlls are copied to the destination folder an jars are created there. The folders lib, bin and include are not created.
It would be nice if the java stuff would happen additionally to the regular installation instead of replacing it.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17182PyPI Installation2020-04-10T13:38:28-04:00Alex KaszynskiPyPI InstallationInstalled vtk using pip "vtk 8.0.0.dev20170717" on Ubuntu with Python3.5. Importing for the first time yields the following:
```
File "/home/user/.local/lib/python3.5/site-packages/vtk/vtkOpenGLKit.py", line 5, in <module>
from .v...Installed vtk using pip "vtk 8.0.0.dev20170717" on Ubuntu with Python3.5. Importing for the first time yields the following:
```
File "/home/user/.local/lib/python3.5/site-packages/vtk/vtkOpenGLKit.py", line 5, in <module>
from .vtkOpenGLKitPython import *
ImportError: libvtkOpenGLKitPython35D-8.1.so.1: cannot open shared object file: No such file or directory
```
It seems python can't find the vtk dynamic libraries. It was fixed by adding the following to ~/.bashrc
```
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/user/.local/lib/python3.5/site-packages/vtk
```
Would be nice for future users if this wasn't necessary.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17166vtk 8.1, pip 9.0.1 , python 3.6, archlinux, ModuleNotFoundError: No module na...2020-04-10T13:37:58-04:00htyeimvtk 8.1, pip 9.0.1 , python 3.6, archlinux, ModuleNotFoundError: No module named 'vtkOpenGLKitPython'When run the demo python program, the following error raise:
```
File "/home/htyeim/anaconda/lib/python3.6/site-packages/vtk/vtkOpenGLKit.py", line 9, in <module>
from vtkOpenGLKitPython import *
ModuleNotFoundError: No modu...When run the demo python program, the following error raise:
```
File "/home/htyeim/anaconda/lib/python3.6/site-packages/vtk/vtkOpenGLKit.py", line 9, in <module>
from vtkOpenGLKitPython import *
ModuleNotFoundError: No module named 'vtkOpenGLKitPython'
```
Then I run the `vtkOpenGLKit.py`.
it says:
```
File "/home/htyeim/anaconda/lib/python3.6/site-packages/vtk/vtkOpenGLKit.py", line 9, in <module>
from vtkOpenGLKitPython import *
ImportError: libvtkOpenGLKitPython36D-8.1.so.1: cannot open shared object file: No such file or directory`
```
but use `ll|grep vtkOpenGLKit` in the vtk folder:
```
-rwxr-xr-x 1 t 1171000 Nov 9 09:07 libvtkOpenGLKitPython36D-8.1.so*
-rwxr-xr-x 1 t 1171000 Nov 9 09:07 libvtkOpenGLKitPython36D-8.1.so.1*
-rw-r--r-- 1 t 315 Nov 9 09:07 vtkOpenGLKit.py
-rwxr-xr-x 1 t 13872 Nov 9 09:07 vtkOpenGLKitPython.so*
```
The file `libvtkOpenGLKitPython36D-8.1.so.1` is in the directory.
So why the No such file or directory error raise?Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17825Java wrappers aren't installed2020-04-09T13:01:05-04:00Kyle EdwardsJava wrappers aren't installedFrom [`Wrapping/Java/CMakeLists.txt`:229-232](https://gitlab.kitware.com/vtk/vtk/-/blob/2258f9fd069d0e5f8aacd34ab6b2db850df3f3ed/Wrapping/Java/CMakeLists.txt#L229):
```cmake
return ()
# Add the option to package VTK for custom Java pac...From [`Wrapping/Java/CMakeLists.txt`:229-232](https://gitlab.kitware.com/vtk/vtk/-/blob/2258f9fd069d0e5f8aacd34ab6b2db850df3f3ed/Wrapping/Java/CMakeLists.txt#L229):
```cmake
return ()
# Add the option to package VTK for custom Java packaging
option(VTK_JAVA_INSTALL "Use the Java rules to build the native libraries." OFF)
```
This seems to have been caused by f324194d279.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17836Add ORDER_DEPENDS for modules2020-04-08T15:53:24-04:00Ben BoeckelAdd ORDER_DEPENDS for modulesSometimes a module must be built before another, but is not needed for linking. In #17835, it is due to CMake variables only guaranteed to be set in that module which end up being used elsewhere.
Cc: @utkarsh.ayachit @brad.king @robertm...Sometimes a module must be built before another, but is not needed for linking. In #17835, it is due to CMake variables only guaranteed to be set in that module which end up being used elsewhere.
Cc: @utkarsh.ayachit @brad.king @robertmaynardBen 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/17827Don't rely on the existence of execinfo2020-04-02T09:07:31-04:00Jürgen FuhrmannDon't rely on the existence of execinfoHi,
one more from the Julia BinaryBuilder:
```
Building CXX object ThirdParty/loguru/vtkloguru/CMakeFiles/loguru.dir/loguru.cpp.o
cd /workspace/srcdir/build/ThirdParty/loguru/vtkloguru && /opt/bin/aarch64-linux-musl-g++ --sysroot=/opt/a...Hi,
one more from the Julia BinaryBuilder:
```
Building CXX object ThirdParty/loguru/vtkloguru/CMakeFiles/loguru.dir/loguru.cpp.o
cd /workspace/srcdir/build/ThirdParty/loguru/vtkloguru && /opt/bin/aarch64-linux-musl-g++ --sysroot=/opt/aarch64-linux-musl/aarch64-linux-musl/sys-root/ -DVTK_IN_VTK -Dloguru_EXPORTS -I/workspace/srcdir/build/ThirdParty/loguru/vtkloguru -I/workspace/srcdir/vtk-496e01f755421cc12dc52d40d8143299af9c6325/ThirdParty/loguru/vtkloguru -isystem /workspace/srcdir/build/ThirdParty/loguru -isystem /workspace/srcdir/vtk-496e01f755421cc12dc52d40d8143299af9c6325/ThirdParty/loguru -O3 -DNDEBUG -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -std=c++11 -o CMakeFiles/loguru.dir/loguru.cpp.o -c /workspace/srcdir/vtk-496e01f755421cc12dc52d40d8143299af9c6325/ThirdParty/loguru/vtkloguru/loguru.cpp
/workspace/srcdir/vtk-496e01f755421cc12dc52d40d8143299af9c6325/ThirdParty/loguru/vtkloguru/loguru.cpp:91:11: fatal error: execinfo.h: No such file or directory
91 | #include <execinfo.h> // for backtrace
| ^~~~~~~~~~~~
compilation terminated.
```
This comes out of cross compiling for a system with the musl libc . Googling of "execinfo.h musl" finds
a number of other such cases. As far as I understand it's not POSIX, so may be it can be #ifdef'ed out with a cmake check...https://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 Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17619vtkLocalExample.java randomly missing from vtk.jar2020-03-23T10:40:21-04:00Bernhard M. WiedemannvtkLocalExample.java randomly missing from vtk.jarWhile working on reproducible builds for openSUSE, I found that
building openSUSE's vtk package resulted in a `vtk.jar`
that only contained the `vtkLocalExample.java` and `vtkLocalExample.class` files
if the build happened in parallel, b...While working on reproducible builds for openSUSE, I found that
building openSUSE's vtk package resulted in a `vtk.jar`
that only contained the `vtkLocalExample.java` and `vtkLocalExample.class` files
if the build happened in parallel, but not with `-j1`
Build logs (with `grep -e vtk.jar -e vtkLocalExample.java`) make it pretty clear that there is some dependency missing in CMakeLists:
```
-j4
vtk/RPMS.2/.build.log:[ 464s] [ 9%] Java Wrappings - generating vtkLocalExample.java
vtk/RPMS.2/.build.log:[ 464s] cd /home/abuild/rpmbuild/BUILD/VTK-8.2.0/build/Examples/Build/vtkLocal && ../../../bin/vtkParseJava @/home/abuild/rpmbuild/BUILD/VTK-8.2.0/build/Examples/Build/vtkLocal/vtkLocalExampleJava.RelWithDebInfo.args -o /home/abuild/rpmbuild/BUILD/VTK-8.2.0/build/java/vtk/vtkLocalExample.java /home/abuild/rpmbuild/BUILD/VTK-8.2.0/Examples/Build/vtkLocal/vtkLocalExample.h
vtk/RPMS.2/.build.log:[ 3533s] cd /home/abuild/rpmbuild/BUILD/VTK-8.2.0/build/Wrapping/Java && /usr/lib64/jvm/java/bin/jar -cvf /home/abuild/rpmbuild/BUILD/VTK-8.2.0/build/lib/vtk.jar -C /home/abuild/rpmbuild/BUILD/VTK-8.2.0/build/java vtk
vtk/RPMS.2/.build.log:[ 3535s] adding: vtk/vtkLocalExample.java(in = 461) (out= 214)(deflated 53%)
vtk/RPMS.2/.build.log:[ 4698s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/vtk-openmpi2-8.2.0-0.0.x86_64/usr/lib64/mpi/gcc/openmpi2/lib64/vtk.jar
-j1
vtk/RPMS/.build.log:[ 7926s] cd /home/abuild/rpmbuild/BUILD/VTK-8.2.0/build/Wrapping/Java && /usr/lib64/jvm/java/bin/jar -cvf /home/abuild/rpmbuild/BUILD/VTK-8.2.0/build/lib/vtk.jar -C /home/abuild/rpmbuild/BUILD/VTK-8.2.0/build/java vtk
vtk/RPMS/.build.log:[12577s] [100%] Java Wrappings - generating vtkLocalExample.java
vtk/RPMS/.build.log:[12577s] cd /home/abuild/rpmbuild/BUILD/VTK-8.2.0/build/Examples/Build/vtkLocal && ../../../bin/vtkParseJava @/home/abuild/rpmbuild/BUILD/VTK-8.2.0/build/Examples/Build/vtkLocal/vtkLocalExampleJava.RelWithDebInfo.args -o /home/abuild/rpmbuild/BUILD/VTK-8.2.0/build/java/vtk/vtkLocalExample.java /home/abuild/rpmbuild/BUILD/VTK-8.2.0/Examples/Build/vtkLocal/vtkLocalExample.h
vtk/RPMS/.build.log:[14008s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/vtk-openmpi2-8.2.0-0.0.x86_64/usr/lib64/mpi/gcc/openmpi2/lib64/vtk.jar
```9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17810python wheel created on OS X leads to broken python module2020-03-20T13:34:45-04:00Noam Bernsteinpython wheel created on OS X leads to broken python moduleI'm trying to use the wheel creation process in the current master (pre-9.0) with macports python 3.8.2. There's also an ongoing discussion at [text](https://discourse.vtk.org/t/python-3-8-wheel-on-mac-os-x/2850/7). I can enable `VTK_BU...I'm trying to use the wheel creation process in the current master (pre-9.0) with macports python 3.8.2. There's also an ongoing discussion at [text](https://discourse.vtk.org/t/python-3-8-wheel-on-mac-os-x/2850/7). I can enable `VTK_BUILD_WHEEL` in cmake, compile, and do `python setup.py bdist_wheel` apparently successfully, but the resulting wheel leads to a broken module. When I try to `import vtk`, I get
```>>> import vtk
Traceback (most recent call last):
File "/Users/bernstei/Library/Python/3.8/lib/python/site-packages/vtkmodules/__init__.py", line 13, in <module>
from . import vtkCommonCore
ImportError: dlopen(/Users/bernstei/Library/Python/3.8/lib/python/site-packages/vtkmodules/vtkCommonCore.cpython-38-darwin.so, 2): Library not loaded: @rpath/libvtkWrappingPythonCore.1.dylib
Referenced from: /Users/bernstei/Library/Python/3.8/lib/python/site-packages/vtkmodules/vtkCommonCore.cpython-38-darwin.so
Reason: image not found
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/bernstei/Library/Python/3.8/lib/python/site-packages/vtk.py", line 30, in <module>
all_m = importlib.import_module('vtkmodules.all')
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "/Users/bernstei/Library/Python/3.8/lib/python/site-packages/vtkmodules/__init__.py", line 15, in <module>
import _vtkmodules_static
ModuleNotFoundError: No module named '_vtkmodules_static'
```
If I add `$HOME/Library/Python/3.8/lib/python/site-packages/vtkmodule` to DYLD_LIBRARY_PATH it works, suggesting to me that the libraries are not in the expected place (either in the wrong place, or not correctly indicating to python or the dyld loader where they are).9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17512libxml2 CMP0075 warnings2020-03-16T14:03:04-04:00Mathieu Westphal (Kitware)libxml2 CMP0075 warningsThe following warnings can be seen when configuring from scratch
```
CMake Warning (dev) at /usr/share/cmake-3.13/Modules/CheckIncludeFiles.cmake:110 (message):
Policy CMP0075 is not set: Include file check macros honor
CMAKE_REQUIR...The following warnings can be seen when configuring from scratch
```
CMake Warning (dev) at /usr/share/cmake-3.13/Modules/CheckIncludeFiles.cmake:110 (message):
Policy CMP0075 is not set: Include file check macros honor
CMAKE_REQUIRED_LIBRARIES. Run "cmake --help-policy CMP0075" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.
CMAKE_REQUIRED_LIBRARIES is set to:
dl;m
For compatibility with CMake 3.11 and below this check is ignoring it.
Call Stack (most recent call first):
VTK/ThirdParty/libxml2/vtklibxml2/CMakeLists.txt:52 (CHECK_INCLUDE_FILES)
VTK/ThirdParty/libxml2/vtklibxml2/CMakeLists.txt:61 (CHECK_INCLUDE_FILE_CONCAT)
This warning is for project developers. Use -Wno-dev to suppress it.
```
and
```
CMake Warning (dev) at /usr/share/cmake-3.13/Modules/CMakeDependentOption.cmake:37 (option):
Policy CMP0077 is not set: option() honors normal variables. Run "cmake
--help-policy CMP0077" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.
For compatibility with older versions of CMake, option is clearing the
normal variable 'VTK_BUILD_QT_DESIGNER_PLUGIN'.
Call Stack (most recent call first):
VTK/GUISupport/Qt/CMakeLists.txt:68 (cmake_dependent_option)
This warning is for project developers. Use -Wno-dev to suppress it.
```9.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/17731Upgrade mpi4py for python 3.82019-12-11T06:56:21-05:00Nicolas VuailleUpgrade mpi4py for python 3.8mpi4py as used in VTK cannot be build with python3.8.
Referring to the upstream repo (https://bitbucket.org/mpi4py/mpi4py/commits/all), the version 3.0.3 should be OK.
Is it possible to upgrade mpi4py ?
* python 3.8.0
* openmpi 4.0.2...mpi4py as used in VTK cannot be build with python3.8.
Referring to the upstream repo (https://bitbucket.org/mpi4py/mpi4py/commits/all), the version 3.0.3 should be OK.
Is it possible to upgrade mpi4py ?
* python 3.8.0
* openmpi 4.0.2
* gcc 9.2.0
* vtk 968566a0697e425ca461f5b93af2ba90964340e2
* cython 0.29.149.0Ben BoeckelBen Boeckel