VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2019-12-11T20:03:16-05:00https://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/17035Build error in release-6.3 branch2018-10-23T13:21:29-04:00medyakovvitBuild error in release-6.3 branchThere is build error in release-6.3 branch in vtkOBJImporterInternals.cpp.
```
101>D:\3rdparty\VTK\repo\IO\Import\vtkOBJImporterInternals.cxx(232): error C2601: 'bindTexturedPolydataToRenderWindow' : local function definitions are illega...There is build error in release-6.3 branch in vtkOBJImporterInternals.cpp.
```
101>D:\3rdparty\VTK\repo\IO\Import\vtkOBJImporterInternals.cxx(232): error C2601: 'bindTexturedPolydataToRenderWindow' : local function definitions are illegal
101> D:\3rdparty\VTK\repo\IO\Import\vtkOBJImporterInternals.cxx(79): this line contains a '{' which has not yet been matched
101>D:\3rdparty\VTK\repo\IO\Import\vtkOBJImporterInternals.cxx(349): error C2065: 'name' : undeclared identifier
101>D:\3rdparty\VTK\repo\IO\Import\vtkOBJImporterInternals.cxx(349): error C2143: syntax error : missing '}' before ';'
101>D:\3rdparty\VTK\repo\IO\Import\vtkOBJImporterInternals.cxx(349): error C2064: term does not evaluate to a function taking 1 arguments
101>D:\3rdparty\VTK\repo\IO\Import\vtkOBJImporterInternals.cxx(350): error C2065: 'name' : undeclared identifier
101>D:\3rdparty\VTK\repo\IO\Import\vtkOBJImporterInternals.cxx(351): error C2664: 'void obj_set_material_defaults(vtkOBJImportedMaterial *)' : cannot convert argument 1 from 'vtkOBJPolyDataProcessor *const ' to 'vtkOBJImportedMaterial *'
101> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
```
Looks like simply on of "}" is missed.https://gitlab.kitware.com/vtk/vtk/-/issues/17069Error building VTK2019-03-20T16:46:12-04:00Bleach665Error building VTKVTK version: v8.0.0.rc2-163-g1b3d7387c5 (from git repo)
OS: Windows 10 x86
CMake version: 3.8.2
Compiler: MSVC 2013
Project was configured by cmake gui.
Cmake changes (command line options in generic):
-DVTK_QT_VERSION:STRIN...VTK version: v8.0.0.rc2-163-g1b3d7387c5 (from git repo)
OS: Windows 10 x86
CMake version: 3.8.2
Compiler: MSVC 2013
Project was configured by cmake gui.
Cmake changes (command line options in generic):
-DVTK_QT_VERSION:STRING="5" -DVTK_RENDERING_BACKEND:STRING="OpenGL" -DCMAKE_INSTALL_PREFIX:PATH="C:/Lib/VTK/build_x86" -DBUILD_TESTING:BOOL="1" -DVTK_Group_Qt:BOOL="1" -DBUILD_EXAMPLES:BOOL="1"
also CMAKE_DEBUG_POSTFIX specified as "d".
Was build by VS2013 x86 Native Tools Command Prompt. Command:
`msbuild VTK.sln /p:configuration=debug`
Received errors:
```
"E:\Lib_prebuild\VTK\x86\VTK.sln" (default target) (1) ->
"E:\Lib_prebuild\VTK\x86\ALL_BUILD.vcxproj.metaproj" (default target) (2) ->
"E:\Lib_prebuild\VTK\x86\GUISupport\QtOpenGL\Testing\Cxx\vtkGUISupportQtOpenGLCxxTests.vcxproj.metaproj" (default target) (458) ->
"E:\Lib_prebuild\VTK\x86\GUISupport\QtOpenGL\Testing\Cxx\vtkGUISupportQtOpenGLCxxTests.vcxproj" (default target) (459) ->
(Link target) ->
TestQVTKWidget2.obj : error LNK2001: unresolved external symbol "protected: virtual void __thiscall QGLWidget::glDraw(void)" (?glDraw@QGLWidget@@MAEXXZ) [
E:\Lib_prebuild\VTK\x86\GUISupport\QtOpenGL\Testing\Cxx\vtkGUISupportQtOpenGLCxxTests.vcxproj]
TestQVTKWidget2.obj : error LNK2001: unresolved external symbol "protected: virtual void __thiscall QGLWidget::glInit(void)" (?glInit@QGLWidget@@MAEXXZ) [
E:\Lib_prebuild\VTK\x86\GUISupport\QtOpenGL\Testing\Cxx\vtkGUISupportQtOpenGLCxxTests.vcxproj]
TestQVTKWidget2.obj : error LNK2001: unresolved external symbol "protected: virtual void __thiscall QGLWidget::initializeOverlayGL(void)" (?initializeOver
layGL@QGLWidget@@MAEXXZ) [E:\Lib_prebuild\VTK\x86\GUISupport\QtOpenGL\Testing\Cxx\vtkGUISupportQtOpenGLCxxTests.vcxproj]
TestQVTKWidget2.obj : error LNK2001: unresolved external symbol "public: virtual class QPaintEngine * __thiscall QGLWidget::paintEngine(void)const " (?pai
ntEngine@QGLWidget@@UBEPAVQPaintEngine@@XZ) [E:\Lib_prebuild\VTK\x86\GUISupport\QtOpenGL\Testing\Cxx\vtkGUISupportQtOpenGLCxxTests.vcxproj]
TestQVTKWidget2.obj : error LNK2001: unresolved external symbol "protected: virtual void __thiscall QGLWidget::paintEvent(class QPaintEvent *)" (?paintEve
nt@QGLWidget@@MAEXPAVQPaintEvent@@@Z) [E:\Lib_prebuild\VTK\x86\GUISupport\QtOpenGL\Testing\Cxx\vtkGUISupportQtOpenGLCxxTests.vcxproj]
TestQVTKWidget2.obj : error LNK2001: unresolved external symbol "protected: virtual void __thiscall QGLWidget::paintOverlayGL(void)" (?paintOverlayGL@QGLW
idget@@MAEXXZ) [E:\Lib_prebuild\VTK\x86\GUISupport\QtOpenGL\Testing\Cxx\vtkGUISupportQtOpenGLCxxTests.vcxproj]
TestQVTKWidget2.obj : error LNK2001: unresolved external symbol "protected: virtual void __thiscall QGLWidget::resizeEvent(class QResizeEvent *)" (?resize
Event@QGLWidget@@MAEXPAVQResizeEvent@@@Z) [E:\Lib_prebuild\VTK\x86\GUISupport\QtOpenGL\Testing\Cxx\vtkGUISupportQtOpenGLCxxTests.vcxproj]
TestQVTKWidget2.obj : error LNK2001: unresolved external symbol "protected: virtual void __thiscall QGLWidget::resizeOverlayGL(int,int)" (?resizeOverlayGL
@QGLWidget@@MAEXHH@Z) [E:\Lib_prebuild\VTK\x86\GUISupport\QtOpenGL\Testing\Cxx\vtkGUISupportQtOpenGLCxxTests.vcxproj]
TestQVTKWidget2.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall QGLWidget::updateGL(void)" (?updateGL@QGLWidget@@UAEXXZ)
[E:\Lib_prebuild\VTK\x86\GUISupport\QtOpenGL\Testing\Cxx\vtkGUISupportQtOpenGLCxxTests.vcxproj]
TestQVTKWidget2.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall QGLWidget::updateOverlayGL(void)" (?updateOverlayGL@QGLWi
dget@@UAEXXZ) [E:\Lib_prebuild\VTK\x86\GUISupport\QtOpenGL\Testing\Cxx\vtkGUISupportQtOpenGLCxxTests.vcxproj]
E:\Lib_prebuild\VTK\x86\bin\Debug\vtkGUISupportQtOpenGLCxxTests.exe : fatal error LNK1120: 10 unresolved externals [E:\Lib_prebuild\VTK\x86\GUISupport\QtO
penGL\Testing\Cxx\vtkGUISupportQtOpenGLCxxTests.vcxproj]
``Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17077Missing __THROW on hypot extern definition in vtklibproj42022-06-22T15:00:52-04:00Chris MarshMissing __THROW on hypot extern definition in vtklibproj4Using g++ 5.4.0 on CentOs 7.3.1611 (Core), I'm unable to compile VTK-8.0.0 as Line 85 of `VTK-8.0.0/ThirdParty/libproj4/vtklibproj4/src/projects.h` has an extern for `hypot` that does not match what is in `mathcalls.h`. Specifically, `ma...Using g++ 5.4.0 on CentOs 7.3.1611 (Core), I'm unable to compile VTK-8.0.0 as Line 85 of `VTK-8.0.0/ThirdParty/libproj4/vtklibproj4/src/projects.h` has an extern for `hypot` that does not match what is in `mathcalls.h`. Specifically, `mathcalls.h` declares `hypot` as `throw()` whereas vtklibproj4 extern does not. Therefore Line 84 needs to be changed from
```extern double hypot(double, double); ```
to
```extern double hypot(double, double) __THROW; ```Ben BoeckelBen Boeckelhttps://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/16871Xdmf3 drops libraries to the build directory root on Windows2019-01-09T15:42:04-05:00Ben BoeckelXdmf3 drops libraries to the build directory root on WindowsXdmf3 is dropping its `.dll` and `.lib` files to the root of the build tree on Windows. The `.dll` needs to go to the `bin` subdirectory and the `.lib` should go to the `lib` directory. I looked at the logic in the Xdmf3 code and I'm not...Xdmf3 is dropping its `.dll` and `.lib` files to the root of the build tree on Windows. The `.dll` needs to go to the `bin` subdirectory and the `.lib` should go to the `lib` directory. I looked at the logic in the Xdmf3 code and I'm not sure enough to go and just remove the wonky MSVC10-guarded blocks (which I don't think should be required at all).
This is causing all of the Python tests to fail on the `nemesis` buildbot (since VTK tries to import all modules in its package's `__init__.py` file.
@joseph.g.hennessey2.ctrBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/16956Qt 5.5.1 + VTK 7.1.02019-07-11T15:18:48-04:00PavelQt 5.5.1 + VTK 7.1.0I have problem with compiling Project with VTK on QtCreator. Please, Help!
OS: Linux Fedora 24
Qt 5.5.1
VTK 7.1.0, собранный с помощью cmake-gui 3.7.1
.pro file
QT += core gui opengl xml
greaterThan(QT_MAJOR_VERSION, 4): QT ...I have problem with compiling Project with VTK on QtCreator. Please, Help!
OS: Linux Fedora 24
Qt 5.5.1
VTK 7.1.0, собранный с помощью cmake-gui 3.7.1
.pro file
QT += core gui opengl xml
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TEMPLATE = app
TARGET = build
DEFINES += “vtkRenderingCore_AUTOINIT=4(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingFreeTypeOpenGL,vtkRenderingOpenGL)”
DEFINES += “vtkRenderingVolume_AUTOINIT=1(vtkRenderingVolumeOpenGL)”
DEFINES += _CRT_SECURE_NO_WARNINGS
INCLUDEPATH += /usr/local/include/vtk-7.1
DEPENDPATH += /usr/local/include/vtk-7.1
LIBS += -L/usr/local/lib \
-lvtkChartsCore-7.1 -lvtkCommonColor-7.1 -lvtkCommonComputationalGeometry-7.1 -lvtkCommonCore-7.1 -lvtkCommonDataModel-7.1 \
-lvtkCommonExecutionModel-7.1 -lvtkCommonMath-7.1 -lvtkCommonMisc-7.1 -lvtkCommonSystem-7.1 -lvtkCommonTransforms-7.1 -lvtkDICOMParser-7.1 \
-lvtkDomainsChemistry-7.1 -lvtkFiltersAMR-7.1 -lvtkFiltersCore-7.1 -lvtkFiltersExtraction-7.1 -lvtkFiltersFlowPaths-7.1 -lvtkFiltersGeneral-7.1 \
-lvtkFiltersGeneric-7.1 -lvtkFiltersGeometry-7.1 -lvtkFiltersHybrid-7.1 -lvtkFiltersHyperTree-7.1 -lvtkFiltersImaging-7.1 \
-lvtkFiltersModeling-7.1 -lvtkFiltersParallel-7.1 -lvtkFiltersParallelImaging-7.1 -lvtkFiltersProgrammable-7.1 -lvtkFiltersSelection-7.1 \
-lvtkFiltersSources-7.1 -lvtkFiltersStatistics-7.1 -lvtkFiltersTexture-7.1 -lvtkFiltersVerdict-7.1 -lvtkGUISupportQt-7.1 \
-lvtkGUISupportQtOpenGL-7.1 -lvtkGeovisCore-7.1 -lvtkIOAMR-7.1 -lvtkIOCore-7.1 -lvtkIOEnSight-7.1 -lvtkIOExodus-7.1 -lvtkIOExport-7.1 \
-lvtkIOGeometry-7.1 -lvtkIOImage-7.1 -lvtkIOImport-7.1 -lvtkIOInfovis-7.1 -lvtkIOLSDyna-7.1 -lvtkIOLegacy-7.1 -lvtkIOMINC-7.1 \
-lvtkIOMovie-7.1 -lvtkIONetCDF-7.1 -lvtkIOPLY-7.1 -lvtkIOParallel-7.1 -lvtkIOSQL-7.1 -lvtkIOVideo-7.1 -lvtkIOXML-7.1 -lvtkIOXMLParser-7.1 \
-lvtkImagingColor-7.1 -lvtkImagingCore-7.1 -lvtkImagingFourier-7.1 -lvtkImagingGeneral-7.1 -lvtkImagingHybrid-7.1 -lvtkImagingMath-7.1 \
-lvtkImagingMorphological-7.1 -lvtkImagingSources-7.1 -lvtkImagingStatistics-7.1 -lvtkImagingStencil-7.1 -lvtkInfovisCore-7.1 \
-lvtkInfovisLayout-7.1 -lvtkInteractionImage-7.1 -lvtkInteractionStyle-7.1 -lvtkInteractionWidgets-7.1 -lvtkNetCDF-7.1 -lvtkNetCDF_cxx-7.1 \
-lvtkParallelCore-7.1 -lvtkRenderingAnnotation-7.1 -lvtkRenderingContext2D-7.1 -lvtkRenderingCore-7.1 -lvtkRenderingFreeType-7.1 \
-lvtkRenderingGL2PS-7.1 -lvtkRenderingImage-7.1 -lvtkRenderingLOD-7.1 -lvtkRenderingLabel-7.1 -lvtkRenderingOpenGL-7.1 -lvtkRenderingVolume-7.1 \
-lvtkRenderingVolumeOpenGL-7.1 -lvtkViewsContext2D-7.1 -lvtkViewsCore-7.1 -lvtkViewsInfovis-7.1 -lvtkalglib-7.1 \
-lvtkexoIIc-7.1 -lvtkexpat-7.1 -lvtkfreetype-7.1 -lvtkgl2ps-7.1 -lvtkhdf5-7.1 -lvtkhdf5_hl-7.1 -lvtkjpeg-7.1 -lvtkjsoncpp-7.1 -lvtklibxml2-7.1 \
-lvtkmetaio-7.1 -lvtkoggtheora-7.1 -lvtkpng-7.1 -lvtkproj4-7.1 -lvtksqlite-7.1 -lvtksys-7.1 -lvtktiff-7.1 -lvtkverdict-7.1 -lvtkzlib-7.1
HEADERS += CustomLinkView.h ui_CustomLinkView.h
FORMS += CustomLinkView.ui
SOURCES += CustomLinkView.cxx main.cxx
RESOURCES += Icons/icons.qrc
ERRORLIST
VTK/Examples/Infovis/Cxx/CustomLinkView/build/CustomLinkView.cxx:-1: ошибка: undefined reference to `vtkQtTreeView::New()'
VTK/Examples/Infovis/Cxx/CustomLinkView/build/CustomLinkView.cxx:-1: ошибка: undefined reference to `vtkQtTableView::New()'
VTK/Examples/Infovis/Cxx/CustomLinkView/build/CustomLinkView.cxx:-1: ошибка: undefined reference to `vtkQtTableView::New()'
VTK/Examples/Infovis/Cxx/CustomLinkView/build/CustomLinkView.cxx:-1: ошибка: undefined reference to `vtkQtTreeView::New()'
VTK/Examples/Infovis/Cxx/CustomLinkView/build/CustomLinkView.cxx:-1: ошибка: undefined reference to `vtkQtTreeView::SetUseColumnView(int)'
VTK/Examples/Infovis/Cxx/CustomLinkView/build/CustomLinkView.cxx:-1: ошибка: undefined reference to `vtkQtTableView::SetSortSelectionToTop(bool)'
VTK/Examples/Infovis/Cxx/CustomLinkView/build/CustomLinkView.cxx:-1: ошибка: undefined reference to `vtkQtTreeView::HideColumn(int)'
VTK/Examples/Infovis/Cxx/CustomLinkView/build/CustomLinkView.cxx:-1: ошибка: undefined reference to `vtkQtTreeView::SetColorArrayName(char const*)'
VTK/Examples/Infovis/Cxx/CustomLinkView/build/CustomLinkView.cxx:-1: ошибка: undefined reference to `vtkQtTreeView::SetColorByArray(bool)'
VTK/Examples/Infovis/Cxx/CustomLinkView/build/CustomLinkView.cxx:-1: ошибка: undefined reference to `vtkQtTreeView::SetColorByArray(bool)'Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/16945VTK-git failed to build against Python 3.5.2 ...2019-07-11T15:16:22-04:00Pei JIAVTK-git failed to build against Python 3.5.2 ...ENV:
Ubuntu 16.04.1
Python 3.5.2
I obtained the following different error messages when building VTK from time to time. Both look like VTK is NOT compatible against Python...
> [ 75%] Built target vtkCommonKitPythonD
> make[1]: ...ENV:
Ubuntu 16.04.1
Python 3.5.2
I obtained the following different error messages when building VTK from time to time. Both look like VTK is NOT compatible against Python...
> [ 75%] Built target vtkCommonKitPythonD
> make[1]: Leaving directory '....../VTK/VTK/build'
> Makefile:141: recipe for target 'all' failed
> make: *** [all] Error 2
> jiapei:build$
> [ 76%] Built target vtkFiltersKitPythonD
> make[1]: Leaving directory '....../VTK/VTK/build'
> Makefile:141: recipe for target 'all' failed
> make: *** [all] Error 2
> jiapei:build$ gedit CMakeFiles/CMakeError.log &
> [2] 11210
> jiapei:build$ ls
Did anybody successfully build VTK against Python 3.5.2???
Cheers,
and happy new year...
PeiBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/16930VERSION support for FindGL2PS.cmake required2019-01-09T15:42:49-05:00Dennis SchriddeVERSION support for FindGL2PS.cmake required[ThirdParty/gl2ps/CMakeLists.txt](https://gitlab.kitware.com/vtk/vtk/blob/6cf5847ef1d21e58cda9953cc654b1025c5668aa/ThirdParty/gl2ps/CMakeLists.txt) requests (via `vtk_module_third_party` in [CMake/vtkModuleMacros.cmake](https://gitlab.ki...[ThirdParty/gl2ps/CMakeLists.txt](https://gitlab.kitware.com/vtk/vtk/blob/6cf5847ef1d21e58cda9953cc654b1025c5668aa/ThirdParty/gl2ps/CMakeLists.txt) requests (via `vtk_module_third_party` in [CMake/vtkModuleMacros.cmake](https://gitlab.kitware.com/vtk/vtk/blob/6cf5847ef1d21e58cda9953cc654b1025c5668aa/CMake/vtkModuleMacros.cmake)) VERSION >=1.4.0 of GL2PS. However, [CMake/FindGL2PS.cmake](https://gitlab.kitware.com/vtk/vtk/blob/6cf5847ef1d21e58cda9953cc654b1025c5668aa/CMake/FindGL2PS.cmake) does not support version tests.
Thus the intention of 1520938bd5bff16d4d81d9628e4405cfc8c118f8, to make sure the system supplied GL2PS is sufficient to compile VTK, is not actually respected and "outdated" installations of GL2PS will not be detected (VTK's version requirement will be ignored).
I discovered this issue during my attempts to compile ParaView 5.2.0, which uses commit 6cf5847ef1d21e58cda9953cc654b1025c5668aa of VTK, authored about two weeks before version 7.1.0 was released.
See-Also: issue #16083Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/16902Undefined Symbols: vtkOBJPolyDataProcessor::New() with dynamically built VTK ...2019-03-21T21:03:12-04:00Seth PUndefined Symbols: vtkOBJPolyDataProcessor::New() with dynamically built VTK libsI've been using the `vtkOBJPolyDataProcessor` to just load and not render some OBJ scenes. Linking against VTK 7.0.0 (from the download tarball), I can link against the class with no problems. However, on the nightly builds (and using Ho...I've been using the `vtkOBJPolyDataProcessor` to just load and not render some OBJ scenes. Linking against VTK 7.0.0 (from the download tarball), I can link against the class with no problems. However, on the nightly builds (and using Homebrew's VTK), I get:
```
Undefined symbols for architecture x86_64:
"vtkOBJPolyDataProcessor::New()", referenced from:
vtkSmartPointer<vtkOBJPolyDataProcessor>::New() in main.cpp.o
ld: symbol(s) not found for architecture x86_64
```
[This zip file](/uploads/e7e10d5b5f87b2d743f299af846990f0/vtkOBJPolyDataProcessorBug.zip) contains a simple enough example to replicate the problem. I'm running OSX 10.11.6, using the Xcode command line tools and CMake for builds.
I'm currently running `git bisect` to see if I can find the commit at which this test code begins to fail, but I'm confused as to why `vtkOBJImporter` compiles if my simple example doesn't. As far as I can tell, `vtkOBJImporter` constructs a `vtkOBJPolyDataProcessor` in the exact same way my example does.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/16831`VTK_USE_BOOST` is obsolete in vtkInfovisBoostGraphAlgorithms2019-03-21T21:03:12-04:00Haocheng LIU`VTK_USE_BOOST` is obsolete in vtkInfovisBoostGraphAlgorithmsThe problem is that the usage of **vtkInfovisBoostGraphAlgorithm** module is dependent on `VTK_USE_BOOST` being defined during the build, but it's defined nowhere. Without boost library, it would never work.
See line 18 of file [vtkCos...The problem is that the usage of **vtkInfovisBoostGraphAlgorithm** module is dependent on `VTK_USE_BOOST` being defined during the build, but it's defined nowhere. Without boost library, it would never work.
See line 18 of file [vtkCosmicTreelayoutStrategy.cxx](https://gitlab.kitware.com/vtk/vtk/blob/master/Infovis/Layout/vtkCosmicTreeLayoutStrategy.cxx).
After discussing with Ben and David Thompson, here is a potential solution:
In pre-VTK-6 releases, one way of dealing with missing library dependencies (i.e., no boost) was to compile the class but have it do nothing. That it the way vtkCosmicTreeLayoutStrategy was written. The VTK_USE_BOOST tests should be removed (so that it will only compile when boost is present) and the class added to a module that is only compiled when boost is present.
It looks like all of these classes need the same treatment:
Layout/vtkCosmicTreeLayoutStrategy.cxx
Layout/vtkTreeLayoutStrategy.cxx
Layout/vtkTreeOrbitLayoutStrategy.cxx
I would recommend adding a VTK/Infovis/BoostLayout module that depends on vtkInfovisLayout and boost; putting all of these classes in it; and removing the VTK_USE_BOOST #ifdefs.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/16814convert projects to the third party update scripts2019-02-23T16:20:46-05:00Ben Boeckelconvert projects to the third party update scriptsProjects:
* [x] alglib
* [x] AutobahnPython
* [x] constantly
* [x] diy2
* [x] exodusII
* [x] expat
* [x] freerange
* [ ] freetype
* [x] gl2ps
* [x] glew
* [x] hdf5
* [x] hyperlink
* [x] incremental
* [x] jpeg
* [x] jsoncp...Projects:
* [x] alglib
* [x] AutobahnPython
* [x] constantly
* [x] diy2
* [x] exodusII
* [x] expat
* [x] freerange
* [ ] freetype
* [x] gl2ps
* [x] glew
* [x] hdf5
* [x] hyperlink
* [x] incremental
* [x] jpeg
* [x] jsoncpp
* [x] libharu
* [x] libproj4
* [x] libxml2
* [x] lz4
* [x] mpi4py
* [ ] netcdf
* [x] oggtheora
* [x] png
* [x] SixPython
* [ ] sqlite
* [ ] TclTk
* [x] tiff
* [x] Twisted
* [x] txaio
* [ ] utf8
* [ ] verdict
* [ ] VPIC
* [x] xdmf2
* [x] xdmf3
* [x] wslink
* [x] zfp
* [x] zlib
* [x] ZopeInterface
* [x] GitSetup (!3457)
* [x] KWIML
* [x] KWSys
* [x] MetaIOBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/16813update module system to use cmake 3.32019-01-09T15:40:09-05:00Ben Boeckelupdate module system to use cmake 3.3VTK's module system should be updated to use CMake's target interfaces so that `target_link_libraries` does all the hard work for us. While at it, the `CMake/` directory should be cleaned up and sorted so that what is private to VTK and ...VTK's module system should be updated to use CMake's target interfaces so that `target_link_libraries` does all the hard work for us. While at it, the `CMake/` directory should be cleaned up and sorted so that what is private to VTK and what is public is clear.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/16803PROJ.4: system library not detected at default location2019-03-21T16:20:12-04:00Kitware RobotPROJ.4: system library not detected at default location**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=16803). Further discussion may take place here.**
---
System libary PROJ.4 isn't detected at the usual FHS locations.
When VTK_USE...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=16803). Further discussion may take place here.**
---
System libary PROJ.4 isn't detected at the usual FHS locations.
When VTK_USE_SYSTEM_LIBRARIES is enabled CMake by default fails with
> [...]
> -- Found TIFF: /usr/lib64/libtiff.so (found version "4.0.6")
> CMake Error at CMake/vtkModuleMacros.cmake:864 (message):
> VTK_USE_SYSTEM_LIBPROJ4 is ON but LIBPROJ4 is not found!
> Call Stack (most recent call first):
> ThirdParty/libproj4/CMakeLists.txt:1 (vtk_module_third_party)
>
>
> -- Configuring incomplete, errors occurred!
besides headers and shared libraries of PROJ.4 are at the usual paths. Both shared libraries and headers of various other dependencies like GDAL, GL2PS or netCDF-C++ legacy are detected at the very same paths. Also, when LIBPROJ4_INCLUDE_DIR and LIBPROJ4_LIBRARIES are set to suitable paths compiling against system PROJ.4 works flawlessly.
Seen compiling recent VTK master commits like 981a1e1 on Arch Linux, Debian stretch (testing) and Fedora 24. Some related discussion took place on vtk-developers, see http://public.kitware.com/pipermail/vtk-developers/2016-July/034005.html.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/15991Build both python2 and python3 binding2022-01-20T12:43:51-05:00Kitware RobotBuild both python2 and python3 binding**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=15991). Further discussion may take place here.**
---
It would be useful to have both python 2 and python3 bindings built at the same...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=15991). Further discussion may take place here.**
---
It would be useful to have both python 2 and python3 bindings built at the same time in the cmake if both version are present. See this downstream feature request (also by myself) for example.
https://bugs.archlinux.org/task/48113?string=vtk&project=5&search_name=vtk&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=https://gitlab.kitware.com/vtk/vtk/-/issues/15895Extra CMAKE_CXX_FLAGS in UseVTK.cmake cause build errors in CMake projects us...2019-03-21T16:16:40-04:00Kitware RobotExtra CMAKE_CXX_FLAGS in UseVTK.cmake cause build errors in CMake projects using VTK**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=15895). Further discussion may take place here.**
---
I'm experiencing a CMake problem caused by UseVTK.cmake (VTK version 6.3 releas...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=15895). Further discussion may take place here.**
---
I'm experiencing a CMake problem caused by UseVTK.cmake (VTK version 6.3 release).
I have a large CMake project with multiple targets. Some use VTK, some use PCL (which uses VTK). One uses neither, but does use the Nvidia CUDA package. Here is what happens:
1) find_package(PCL) in my CMake code automatically runs PCLConfig.cmake.
2) PCLConfig.cmake includes UseVTK.cmake after find_package(VTK) is successful (note: this is the intended use, I'm assuming there is nothing wrong with this).
3) UseVTK.cmake adds a trainload of flags to CMAKE_C_FLAGS and CMAKE_CXX_FLAGS CMake variables directly (Something wrong with this schema -- discussed later).
4) Even though a certain target does not link/use VTK or PCL, the way the CMake default CUDA handling works is that these flags are passed to the nvcc compiler, i.e. here's what gets executed:
---------begin quote-----------
/usr/local/cuda/bin/nvcc -M -D__CUDACC__ /home/<omitted>/quickshift_gpu.cu -o /home/<omitted>/reco_segmentation_generated_quickshift_gpu.cu.o.NVCC-depend -ccbin /usr/bin/c++ -m64 -D_DEBUG -DvtkRenderingContext2D_AUTOINIT=1 ( vtkRenderingContextOpenGL ) -DvtkRenderingCore_AUTOINIT=3 ( vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL ) -DvtkRenderingVolume_AUTOINIT=1 ( vtkRenderingVolumeOpenGL ) -Dreco_segmentation_EXPORTS -Xcompiler ,\"-Wall\",\"-std=c++11\",\"-fPIC\",\"-g\" -DNVCC -I/usr/local/cuda/include -I/usr/local/include/vtk-6.3 -I/usr/local/cuda/include
---------end quote-------------
-- instead of simply:
---------begin quote-----------
/usr/local/cuda/bin/nvcc /home/<omitted>/quickshift_gpu.cu -c -o /home/<omitted>/reco_segmentation_generated_quickshift_gpu.cu.o -ccbin /usr/bin/c++ -m64 -D_DEBUG -Dreco_segmentation_EXPORTS -Xcompiler ,\"-Wall\",\"-std=c++11\",\"-fPIC\",\"-g\" -DNVCC -I/usr/local/cuda/include -I/usr/local/cuda/include
---------end quote-------------
Whereas the latter command funs fine, the former fails with "nvcc fatal : A single input file is required for a non-link phase when an outputfile is specified".
Discussion: syntax such as "set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${VTK_REQUIRED_CXX_FLAGS}")" is really not supposed to be used in UseXXX.CMake files, that file is intended for CMake macros/functions(1). Clearly, it causes unintended problems. The modern way to do things like this is to add the flags to something like VTK_CXX_FLAGS, so that the user may use the target_compile_definitions(...) command (2) to add them to specific targets. Ideally, off course, the preprocessor definitions should be set in config header files that are configured by cmake *at the time of VTK CMake generation*, such as /Common/Core/vtkConfigure.h.in. This way they are defined when the target project includes the headers (which is done any way), and avoid the need for separate target_compile_definitions calls.
1) How do I get around this and get CUDA working on this target without losing PCL/VTK support for other targets? (Currently, I am actually clearing these out via CMake scripting from the COMPILE_DEFINITIONS property of the subproject's directory using the remove_definitions function).
2) Is there any rationale behind setting compiler flags in CMake instead of in header config files? Is there any rationale behind explicitly modifying the CMake flags variables in the UseVTK.cmake script?
[1] https://cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file
[2] https://cmake.org/cmake/help/v3.2/command/target_compile_definitions.htmlBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17144call of overloaded ‘sqrt(double)’ is ambiguous2019-04-19T15:12:12-04:00Algis Džiugyscall of overloaded ‘sqrt(double)’ is ambiguousDuring compilation of the code including VTK v.8.0.1 and OpenFOAM v.5.0, c++ compiler reports errors "**call of overloaded ‘sqrt(double)’ is ambiguous**" in:
* vtkMath.h:432:58: In static member function ‘static double vtkMath::Norm(con...During compilation of the code including VTK v.8.0.1 and OpenFOAM v.5.0, c++ compiler reports errors "**call of overloaded ‘sqrt(double)’ is ambiguous**" in:
* vtkMath.h:432:58: In static member function ‘static double vtkMath::Norm(const double*)’: static double Norm(const double v[3]) {return sqrt( v[0] * v[0] + v[1] * v[1] + v[2] * v[2] );};
* vtkMath.h:572:44: In static member function ‘static double vtkMath::Norm2D(const double*)’: static double Norm2D(const double x[2]) {return sqrt( x[0] * x[0] + x[1] * x[1] );};
* vtkVector.h:80:57: In member function ‘double vtkVector<T, Size>::Norm() const’: double Norm() const {return sqrt(static_cast<double>(this->SquaredNorm()));}
* vtkTriangle.h:271:58: In static member function ‘static void vtkTriangle::ComputeNormal(double*, double*, double*, double*)’:
I suppose, that solution could be to define explicitly namespace for sqrt() and other mathematics functions in VTK.
Best regards,
AlgisBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17145Generating wrapper source files depends on target dependencies2019-03-20T12:02:22-04:00Ben BoeckelGenerating wrapper source files depends on target dependenciesWrapper source files should only depend on the hierarchy file, the header source, and the tool used to generate the source code.
This may be a CMake limitation with custom commands (see cmake/cmake!1103).
Cc: @brad.king @dgobbiWrapper source files should only depend on the hierarchy file, the header source, and the tool used to generate the source code.
This may be a CMake limitation with custom commands (see cmake/cmake!1103).
Cc: @brad.king @dgobbiBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/15730Use system utf8cpp2019-03-20T21:03:13-04:00Kitware RobotUse system utf8cpp**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=15730). Further discussion may take place here.**
---
Want to be able to build against the system utf8cpp, but vtk's names are mangle...**This issue was created automatically from an original [Mantis Issue](http://vtk.org/Bug/view.php?id=15730). Further discussion may take place here.**
---
Want to be able to build against the system utf8cpp, but vtk's names are mangled with vtk_.
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/17169CMake/FindOSPRay looking for old nonexistent library2018-10-23T13:19:40-04:00Paul NavrátilCMake/FindOSPRay looking for old nonexistent libraryUsing the VTK submodule from the ParaView gitlab repo, the FindOSPRay in VTK/CMake is looking for lib_ospray_embree.so, which is no longer produced by OSPRay (and apparently hasn't been for some time). As of
This mod removes the issue ...Using the VTK submodule from the ParaView gitlab repo, the FindOSPRay in VTK/CMake is looking for lib_ospray_embree.so, which is no longer produced by OSPRay (and apparently hasn't been for some time). As of
This mod removes the issue and allows a successful OSPRay-enabled build (VTK tag 650db03):
```diff
diff --git a/CMake/FindOSPRay.cmake b/CMake/FindOSPRay.cmake
index 380195b..19a023a 100644
--- a/CMake/FindOSPRay.cmake
+++ b/CMake/FindOSPRay.cmake
@@ -54,10 +54,10 @@ else()
${OSPRAY_SOURCE_DIR}/components
)
- set(LIB_OSPRAY_EMBREE LIB_OSPRAY_EMBREE-NOTFOUND)
- find_library(LIB_OSPRAY_EMBREE NAMES ospray_embree embree
- PATHS ${OSPRAY_BUILD_DIR} ${OSP_embree_DIR} NO_DEFAULT_PATH)
- mark_as_advanced(LIB_OSPRAY_EMBREE)
+ #set(LIB_OSPRAY_EMBREE LIB_OSPRAY_EMBREE-NOTFOUND)
+ #find_library(LIB_OSPRAY_EMBREE NAMES ospray_embree embree
+ # PATHS ${OSPRAY_BUILD_DIR} ${OSP_embree_DIR} NO_DEFAULT_PATH)
+ #mark_as_advanced(LIB_OSPRAY_EMBREE)
set(LIB_OSPRAY_COMMON LIB_OSPRAY_COMMON-NOTFOUND)
find_library(LIB_OSPRAY_COMMON ospray_common
@@ -68,7 +68,8 @@ else()
find_library(LIB_OSPRAY ospray PATHS ${OSPRAY_BUILD_DIR} NO_DEFAULT_PATH)
mark_as_advanced(LIB_OSPRAY)
- set(OSPRAY_LIBRARIES ${LIB_OSPRAY_EMBREE} ${LIB_OSPRAY_COMMON} ${LIB_OSPRAY})
+ #set(OSPRAY_LIBRARIES ${LIB_OSPRAY_EMBREE} ${LIB_OSPRAY_COMMON} ${LIB_OSPRAY})
+ set(OSPRAY_LIBRARIES ${LIB_OSPRAY_COMMON} ${LIB_OSPRAY})
```https://gitlab.kitware.com/vtk/vtk/-/issues/17172Move legacy data to the appropriate modules2019-01-09T15:45:58-05:00Ben BoeckelMove legacy data to the appropriate modulesThere is the `CMake/vtkLegacyData.cmake` module which downloads data for modules that haven't been converted to be modularized yet. All of these are unconditionally downloaded when testing is enabled. Let's complete this migration.
- ...There is the `CMake/vtkLegacyData.cmake` module which downloads data for modules that haven't been converted to be modularized yet. All of these are unconditionally downloaded when testing is enabled. Let's complete this migration.
- [ ] `FiberSurface` (goes to `Filters/Topology`)
- [ ] `Infovis` (goes to `Examples/Infovis`, `IO/Infovis`, `Infovis/BoostGraphAlgorithms`, `Infovis/Core`, `Infovis/Layout`, and `Views/Infovis`)
- [ ] `Infovis/DimacsGraphs` (goes to `IO/Infovis`)
- [ ] `Infovis/Images` (goes to `Examples/Infovis`)
- [ ] `Infovis/SQLite` (goes to `Examples/Infovis` and `Views/Infovis`)
- [ ] `Infovis/XML` (goes to `Examples/Infovis`, `IO/Infovis`, and `Views/Infovis`)
- [ ] `Tango` (goes to `Filters/General`, `Rendering/Core`, and `Views/Infovis`)
- [ ] `SemiDisk` (goes to `Filters/Modeling` and `Filters/Selection`)
- [ ] `GIS` (goes to `IO/GDAL`)
- [ ] `many_blocks` (goes to `Rendering/{OSPRay,OpenGL,OptiX}`)
- [ ] `Quadratic` (goes to `Filters/General`)
- [ ] `Dave_Karelitz_Small` (unused?)
- [ ] `MetaIO` (unused?)
- [ ] `libtiff` (goes to `IO/Image` and `Imaging/Color`)
- [ ] `AMR/Enzo` (goes to `Filters/{AMR,Core,ParallelFlowPaths}` and `IO/{AMR,Geometry}`)
- [ ] `AMR/HierarchicalBoxDataSet*` (goes to `IO/XML`)
- [ ] `AMR` (goes to `IO/XML`)
- [ ] `UCD2D` (goes to `Examples/Graphics` and `Filters/General`)
- [ ] `ex-blow_5` (goes to `Rendering/LIC{,OpenGL2}`)
- [ ] `chombo3d` (goes to `Examples/AMR` and `Rendering/Core`)
- [ ] `foot` (goes to `IO/Image` and `Imaging/{General,Morphological}`)
- [ ] `chi_field` (unused?)
- [ ] `headsq` (used all over the place)
- [ ] `Viewpoint` (used in `Examples/{Rendering,Visualization}`, `Filters/Core`, `IO/Export`, and `Rendering/Core`)
- [ ] `EnSight` (used in `Filters/General` and `IO/EnSight`)
- [ ] `Delaunay` (used in `Filters/Core`)
- [ ] `headmr3blocks` (used in `Rendering/Volume`)
Cc: @utkarsh.ayachit @berkgeveci @shawn.waldonBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17173Clean up warning regex exclusions2019-02-13T09:39:50-05:00Ben BoeckelClean up warning regex exclusionsThis list has been accumulating over a long time. We should figure out what's important to keep, whether more local suppression makes sense, adding flags to suppress classes of warnings, or (preferrably) actually fix the warnings. This i...This list has been accumulating over a long time. We should figure out what's important to keep, whether more local suppression makes sense, adding flags to suppress classes of warnings, or (preferrably) actually fix the warnings. This is because this list is only applicable on CDash; developers still see the warnings when compiling.
Third party libraries should suppress warnings on their own rather than relying on this list anyways.
Cc: @utkarsh.ayachit @berkgeveci @shawn.waldonhttps://gitlab.kitware.com/vtk/vtk/-/issues/17174used qt5.9.2 mingw build fail [ 91%] Linking CXX shared library ..\..\bin\lib...2018-11-30T13:12:20-05:00Sindenused qt5.9.2 mingw build fail [ 91%] Linking CXX shared library ..\..\bin\libvtkIOExport-8.0d.dll```
CMakeFiles\vtkIOExport.dir/objects.a(vtkPDFExporter.cxx.obj): In function `ZN14vtkPDFExporter9WriteDataEv':
F:/ThirdParty/src/VTK-8.0.1/IO/Export/vtkPDFExporter.cxx:99: undefined reference to `vtk_haru_HPDF_New'
F:/ThirdParty/src/VTK...```
CMakeFiles\vtkIOExport.dir/objects.a(vtkPDFExporter.cxx.obj): In function `ZN14vtkPDFExporter9WriteDataEv':
F:/ThirdParty/src/VTK-8.0.1/IO/Export/vtkPDFExporter.cxx:99: undefined reference to `vtk_haru_HPDF_New'
F:/ThirdParty/src/VTK-8.0.1/IO/Export/vtkPDFExporter.cxx:109: undefined reference to `vtk_haru_HPDF_SaveToFile'
F:/ThirdParty/src/VTK-8.0.1/IO/Export/vtkPDFExporter.cxx:116: undefined reference to `vtk_haru_HPDF_Free'
CMakeFiles\vtkIOExport.dir/objects.a(vtkPDFExporter.cxx.obj): In function `ZN14vtkPDFExporter15PrepareDocumentEv':
F:/ThirdParty/src/VTK-8.0.1/IO/Export/vtkPDFExporter.cxx:130: undefined reference to `vtk_haru_HPDF_SetCompressionMode'
F:/ThirdParty/src/VTK-8.0.1/IO/Export/vtkPDFExporter.cxx:134: undefined reference to `vtk_haru_HPDF_SetInfoAttr'
F:/ThirdParty/src/VTK-8.0.1/IO/Export/vtkPDFExporter.cxx:136: undefined reference to `vtk_haru_HPDF_SetInfoAttr'
F:/ThirdParty/src/VTK-8.0.1/IO/Export/vtkPDFExporter.cxx:138: undefined reference to `vtk_haru_HPDF_AddPage'
F:/ThirdParty/src/VTK-8.0.1/IO/Export/vtkPDFExporter.cxx:139: undefined reference to `vtk_haru_HPDF_Page_SetWidth'
F:/ThirdParty/src/VTK-8.0.1/IO/Export/vtkPDFExporter.cxx:140: undefined reference to `vtk_haru_HPDF_Page_SetHeight'
collect2.exe: error: ld returned 1 exit status
IO\Export\CMakeFiles\vtkIOExport.dir\build.make:544: recipe for target 'bin/libvtkIOExport-8.0d.dll' failed
mingw32-make[2]: *** [bin/libvtkIOExport-8.0d.dll] Error 1
CMakeFiles\Makefile2:6252: recipe for target 'IO/Export/CMakeFiles/vtkIOExport.dir/all' failed
mingw32-make[1]: *** [IO/Export/CMakeFiles/vtkIOExport.dir/all] Error 2
Makefile:128: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
```https://gitlab.kitware.com/vtk/vtk/-/issues/17178CHECK_SYMBOL_EXISTS fails to find PTHREAD_MUTEX_RECURSIVE on FreeBSD2019-03-21T15:12:46-04:00yurivictCHECK_SYMBOL_EXISTS fails to find PTHREAD_MUTEX_RECURSIVE on FreeBSDThe build of 8.0.1 fails on the FreeBSD due to this line:
```CHECK_SYMBOL_EXISTS(PTHREAD_MUTEX_RECURSIVE pthread.h HAVE_PTHREAD_MUTEX_RECURSIVE_DEFN)```
The cmake test error:
```
/usr/ports/math/vtk/tmp/CMakeFiles/CMakeTmp/CheckSymbol...The build of 8.0.1 fails on the FreeBSD due to this line:
```CHECK_SYMBOL_EXISTS(PTHREAD_MUTEX_RECURSIVE pthread.h HAVE_PTHREAD_MUTEX_RECURSIVE_DEFN)```
The cmake test error:
```
/usr/ports/math/vtk/tmp/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:18: error: cannot take the address of an rvalue of type 'int'
return ((int*)(&PTHREAD_MUTEX_RECURSIVE))[argc];
^~~~~~~~~~~~~~~~~~~~~~~~
```
This symbol (enum) actually exists.8.2.1Ben 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/17193CMake IMPORTED module targets are incomplete2019-01-09T15:41:52-05:00Taylor Braun-JonesCMake IMPORTED module targets are incompleteThe imported targets for each VTK module are missing information like include directories, compile definitions, etc. For example, currently for `vtkCommonMath` there is the following in `VTKTargets*.cmake`:
```
# Create imported target ...The imported targets for each VTK module are missing information like include directories, compile definitions, etc. For example, currently for `vtkCommonMath` there is the following in `VTKTargets*.cmake`:
```
# Create imported target vtkCommonMath
add_library(vtkCommonMath SHARED IMPORTED)
set_target_properties(vtkCommonMath PROPERTIES
INTERFACE_COMPILE_FEATURES "cxx_nullptr"
INTERFACE_LINK_LIBRARIES "vtkCommonCore"
)
# Import target "vtkCommonMath" for configuration "RelWithDebInfo"
set_property(TARGET vtkCommonMath APPEND PROPERTY IMPORTED_CONFIGURATIONS RELWITHDEBINFO)
set_target_properties(vtkCommonMath PROPERTIES
IMPORTED_IMPLIB_RELWITHDEBINFO "${_IMPORT_PREFIX}/lib/vtkCommonMath-8.0.lib"
IMPORTED_LOCATION_RELWITHDEBINFO "${_IMPORT_PREFIX}/bin/vtkCommonMath-8.0.dll"
)
list(APPEND _IMPORT_CHECK_TARGETS vtkCommonMath )
list(APPEND _IMPORT_CHECK_FILES_FOR_vtkCommonMath "${_IMPORT_PREFIX}/lib/vtkCommonMath-8.0.lib" "${_IMPORT_PREFIX}/bin/vtkCommonMath-8.0.dll" )
```
What's missing is something like:
```
set_target_properties(vtkCommonMath PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "${vtkCommonMath_INCLUDE_DIRS}"
)
set_target_properties(vtkCommonMath PROPERTIES
INTERFACE_COMPILE_DEFINITIONS "${vtkCommonMath_DEFINITIONS}"
)
```Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17209vtkLocalExampleHierarchy.txt not found installing the latest master version o...2019-01-09T15:46:32-05:00fifothekidvtkLocalExampleHierarchy.txt not found installing the latest master version on WindowsI'm compiling VTK using the latest version of Visual Studio 2017. Compilation is working perfectly for all modules including the examples.
However, when I try building the INSTALL project in order to copy the files to appropriate direct...I'm compiling VTK using the latest version of Visual Studio 2017. Compilation is working perfectly for all modules including the examples.
However, when I try building the INSTALL project in order to copy the files to appropriate directories most of the modules are installed except for the examples due to the file vtkLocalExampleHierarchy.txt which could not be located in the build directory.
Any suggestions?Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17235Header depends for Python wrapper targets aren't updated2023-11-19T11:36:05-05:00David GobbiHeader depends for Python wrapper targets aren't updatedWhen header files are removed from VTK, they sometimes still appear in the "make" dependencies of the Python wrapper library/module targets. The result is that removing a header file might cause the build to fail, with "make" complainin...When header files are removed from VTK, they sometimes still appear in the "make" dependencies of the Python wrapper library/module targets. The result is that removing a header file might cause the build to fail, with "make" complaining that the header file is needed and is missing.
This occurs because the dependency is generated by the add\_custom\_command() call in vtkWrapPython.cmake, which uses IMPLICIT\_DEPENDS to scan the wrapped header for \#include directives. The list of header dependencies is updated only when the custom command is updated, and removing a header file does not trigger such an update.
A discussion, and a possible fix, is provided in cmake/cmake#16830.David GobbiDavid Gobbihttps://gitlab.kitware.com/vtk/vtk/-/issues/17267Building an external VTK module generate a hierarchy file in VTK build directory2019-02-01T11:22:53-05:00Mathieu Westphal (Kitware)Building an external VTK module generate a hierarchy file in VTK build directoryWhen building an external VTK module, a hierachy file is generated in the build of VTK.
How to reproduce :
* Build VTK
* `ls vtk_build/lib/cmake/vtk-9.0/Modules/vtkMyFiltersHierarchy.txt
ls: cannot access vtkMyFiltersHierarchy.txt: N...When building an external VTK module, a hierachy file is generated in the build of VTK.
How to reproduce :
* Build VTK
* `ls vtk_build/lib/cmake/vtk-9.0/Modules/vtkMyFiltersHierarchy.txt
ls: cannot access vtkMyFiltersHierarchy.txt: No such file or directory`
* untar [SimpleModule.tgz](/uploads/ee41139bbc4570a9834f81f24b102c5a/SimpleModule.tgz)
* cd ~/SimpleModule
* mkdir build
* cd build
* cmake -DVTK_DIR=/path/to/VTK/build/ ..
* make
* `[...] For vtkMyFilters - updating vtkMyFiltersHierarchy.txt`
* `ls vtk_build/lib/cmake/vtk-9.0/Modules/vtkMyFiltersHierarchy.txt
vtk_build/lib/cmake/vtk-9.0/Modules/vtkMyFiltersHierarchy.txt`
It can be a very big problem, we definitelly cannot assume external module builder have write access on VTK build directory.
This directory is defined by VTK_MODULES_DIR, which is defined during VTK configuration in VTKConfig.cmake.
Somehow related to paraview/paraview#17982 and !3493 paraview/paraview!2366Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17285Build fails with clang-62018-10-23T10:38:06-04:00yurivictBuild fails with clang-6The FreeBSD port (version vtk6-6.2.0) fails with these errors on FreeBSD 12:
```
/wrkdirs/usr/ports/math/vtk6/work/VTK-6.2.0/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx:389:20: error: static_cast from 'nullptr_t' to 'Window' (aka 'unsi...The FreeBSD port (version vtk6-6.2.0) fails with these errors on FreeBSD 12:
```
/wrkdirs/usr/ports/math/vtk6/work/VTK-6.2.0/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx:389:20: error: static_cast from 'nullptr_t' to 'Window' (aka 'unsigned long') is not allowed
this->ParentId = static_cast<Window>(NULL);
^~~~~~~~~~~~~~~~~~~~~~~~~
/wrkdirs/usr/ports/math/vtk6/work/VTK-6.2.0/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx:397:20: error: static_cast from 'nullptr_t' to 'Window' (aka 'unsigned long') is not allowed
this->WindowId = static_cast<Window>(NULL);
^~~~~~~~~~~~~~~~~~~~~~~~~
/wrkdirs/usr/ports/math/vtk6/work/VTK-6.2.0/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx:398:24: error: static_cast from 'nullptr_t' to 'Window' (aka 'unsigned long') is not allowed
this->NextWindowId = static_cast<Window>(NULL);
^~~~~~~~~~~~~~~~~~~~~~~~~
/wrkdirs/usr/ports/math/vtk6/work/VTK-6.2.0/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx:779:22: error: static_cast from 'nullptr_t' to 'Window' (aka 'unsigned long') is not allowed
this->WindowId = static_cast<Window>(NULL);
^~~~~~~~~~~~~~~~~~~~~~~~~
/wrkdirs/usr/ports/math/vtk6/work/VTK-6.2.0/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx:1171:24: error: static_cast from 'nullptr_t' to 'Window' (aka 'unsigned long') is not allowed
this->NextWindowId = static_cast<Window>(NULL);
^~~~~~~~~~~~~~~~~~~~~~~~~
```https://gitlab.kitware.com/vtk/vtk/-/issues/17295Typo in VTKm cmakelist.txt2018-10-23T12:04:16-04:00Gustavo AlvarezTypo in VTKm cmakelist.txthttps://gitlab.kitware.com/vtk/vtk/blob/80814113457ecec301a92edee556e51c7722a974/ThirdParty/vtkm/CMakeLists.txt#L28
seems needs add DEFINED
if(VTK_CUSTOM_LIBRARY_SUFFIX)
to
if(DEFINED VTK_CUSTOM_LIBRARY_SUFFIX)
if not, altho...https://gitlab.kitware.com/vtk/vtk/blob/80814113457ecec301a92edee556e51c7722a974/ThirdParty/vtkm/CMakeLists.txt#L28
seems needs add DEFINED
if(VTK_CUSTOM_LIBRARY_SUFFIX)
to
if(DEFINED VTK_CUSTOM_LIBRARY_SUFFIX)
if not, although set VTK_CUSTOM_LIBRARY_SUFFIX/VTKm_CUSTOM_LIBRARY_SUFFIX, always is set to
-vtk${VTK_MAJOR_VERSION}.${VTK_MINOR_VERSION}
greetingsRobert MaynardRobert Maynardhttps://gitlab.kitware.com/vtk/vtk/-/issues/17296How to include VTK libraries into my project2019-04-18T05:29:34-04:00MabroukHow to include VTK libraries into my projectI have already installed VTK and ITK on my machine (linux). Now, I am trying to read a nifti image, so I used a code to read it. I have to include some VTK libraries in the beginning like:
#include vtkImageData.h
#include vtkMetaImageR...I have already installed VTK and ITK on my machine (linux). Now, I am trying to read a nifti image, so I used a code to read it. I have to include some VTK libraries in the beginning like:
#include vtkImageData.h
#include vtkMetaImageReader.h
#include vtkSmartPointer.h
#include vtkInteractorStyleImage.h
#include vtkRenderer.h
#include vtkImageActor.h
#include vtkImageMapper3D.h
#include vtkImageReader.h
#include vtkRenderWindow.h
I need to use this class:
vtkSmartPointer<vtkMetaImageReader> mMetaReader = vtkSmartPointer<vtkMetaImageReader>::New();
Still, they are unresolved. Although, I have run "cmake" in project directory, and I have specified VTK path.
Any help is very appreciated. Thank you!https://gitlab.kitware.com/vtk/vtk/-/issues/17306mpi4py compile error using SGI's MPT mpi implementation2019-05-02T13:22:50-04:00Andrew Bauermpi4py compile error using SGI's MPT mpi implementationThe compile error is:
```
/p/home/joeh/PV/Build_5.5.0_gl2_qt510/superbuild/paraview/src/VTK/ThirdParty
/mpi4py/vtkmpi4py/src/mpi4py.MPI.c:142544:16: error:
'MPI_CONVERSION_FN_NULL' undeclared (first use in this function)
__pyx_v_rd = ...The compile error is:
```
/p/home/joeh/PV/Build_5.5.0_gl2_qt510/superbuild/paraview/src/VTK/ThirdParty
/mpi4py/vtkmpi4py/src/mpi4py.MPI.c:142544:16: error:
'MPI_CONVERSION_FN_NULL' undeclared (first use in this function)
__pyx_v_rd = MPI_CONVERSION_FN_NULL;
```
There is a working fix at https://gitlab.kitware.com/vtk/vtk/merge_requests/4257 but it needs to be upstreamed first and then brought back into VTK's 3rd party source.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17314Add liblz4 to library search names in FindLZ4.cmake2019-05-31T10:03:05-04:00jakirkhamAdd liblz4 to library search names in FindLZ4.cmakeWould be nice to include `liblz4` in addition to `lz4` in the library names searched for by `FindLZ4.cmake`.Would be nice to include `liblz4` in addition to `lz4` in the library names searched for by `FindLZ4.cmake`.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17322libvtkexpat has undefined reference linking error in Paraview 5.5.0 by default2019-03-20T17:01:02-04:00Jon Roodlibvtkexpat has undefined reference linking error in Paraview 5.5.0 by defaultSeems to be a VTK issue, but it's impacting Paraview 5.5.0 for me. I am seeing a linking error in VTK expat where `arc4random_buf` is undefined. I am building on CentOS 7 with GCC 6.2.0. Looking at Paraview 5.4.1 which I can successfully...Seems to be a VTK issue, but it's impacting Paraview 5.5.0 for me. I am seeing a linking error in VTK expat where `arc4random_buf` is undefined. I am building on CentOS 7 with GCC 6.2.0. Looking at Paraview 5.4.1 which I can successfully build in the same setting, VTK expat is much different and doesn't have anything involving libbsd there. I've been trying to understand how I can workaround this, but am having trouble getting it to choose the right random number function. I have libbsd available which is supposed to have that symbol. It appears that the libbsd stuff is all forcibly shut off in CMakeLists.txt, but somehow the preprocessor defines are still letting this symbol in.
```
lib/libvtkexpat-pv5.5.so.1: undefined reference to `arc4random_buf'
collect2: error: ld returned 1 exit status
```Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17336Cmake with VTK 8.1.1 with build examples turned on with Qt 5.11 gives a block...2018-10-23T16:40:53-04:00RickCmake with VTK 8.1.1 with build examples turned on with Qt 5.11 gives a blocking error.Cmake with VTK 8.1.1 with build examples turned on with Qt 5.11 gives me the following
CMake Error at Examples/Infovis/Cxx/EasyView/CMakeLists.txt:77 (qt5_use_modules):
Unknown CMake command "qt5_use_modules".Cmake with VTK 8.1.1 with build examples turned on with Qt 5.11 gives me the following
CMake Error at Examples/Infovis/Cxx/EasyView/CMakeLists.txt:77 (qt5_use_modules):
Unknown CMake command "qt5_use_modules".https://gitlab.kitware.com/vtk/vtk/-/issues/17349There are two problems in VTK 8.1.1 building with CMake2019-04-11T09:54:17-04:00minhphuoc hongThere are two problems in VTK 8.1.1 building with CMakeI am using Windows 10 (64 bits), CMake 3.11.4 and Visual Studio 2015 (64 bits) to build VTK 8.1.1. But there are two following problems:
1. If I turn on BUILD_EXAMPLES in CMake, there is an error message when build the "ALL BUILD" proje...I am using Windows 10 (64 bits), CMake 3.11.4 and Visual Studio 2015 (64 bits) to build VTK 8.1.1. But there are two following problems:
1. If I turn on BUILD_EXAMPLES in CMake, there is an error message when build the "ALL BUILD" project in the visual studio 2015. The error message "Cannot open include file: 'vtkRegressionTestImage.h': No such file or directory".
2. If I turn on Module_vtkSupportMFC and VTK_RENDERING_BACKEND is OpenGL2 in the CMake, I cannot build the "ALL_BUILD" project in the visual studio 2015. However, if I change the VTK_RENDERING_BACKEND value from OpenGL2 to OpenGL, everything is fine.
Is there anyway to fix those problems? I want to use OpenGL2 and turn on Module_vtkSupportMFC in VTK 8.1.1Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17361VTK compile definitions causing warnings in the compiler2019-03-20T17:33:21-04:00Gregory KramidaVTK compile definitions causing warnings in the compilerNB: There is an easy fix (see below)! But tracking it down took so much work that I just made a local patch for my project instead of a PR here...
Using VTK with another project via CMake, I encountered this (many, many times) during c...NB: There is an easy fix (see below)! But tracking it down took so much work that I just made a local patch for my project instead of a PR here...
Using VTK with another project via CMake, I encountered this (many, many times) during compilation:
<command-line>:0:20: warning: ISO C++11 requires whitespace after the macro name
I've tracked it down to this compile definition:
-DvtkRenderingCore_AUTOINIT=3"(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL2)"
The warning disappears after placing a space after each item in the list, i.e.:
-DvtkRenderingCore_AUTOINIT=3"(vtkInteractionStyle ,vtkRenderingFreeType ,vtkRenderingOpenGL2 )"
(Aside) In the COMPILE_DEFINITIONS property as well as the ${VTK_DEFINITIONS} variable in CMake, this appears without quotes, like this: -DvtkRenderingCore_AUTOINIT=3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL2)
VTK Version 8.1.1, compiled from source, g++ 5.4.0, Ubuntu 16.04Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17374Building vtkAcceleratorsVTKm module in VTK 8.1.1 fails2018-10-23T09:51:10-04:00Ghost UserBuilding vtkAcceleratorsVTKm module in VTK 8.1.1 failsWindows 10 / Visual Studio 2017 / Cuda 9.2
During building VTK with enabled vtkAcceleratorsVTKm module I get these errors:
```
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\device\...Windows 10 / Visual Studio 2017 / Cuda 9.2
During building VTK with enabled vtkAcceleratorsVTKm module I get these errors:
```
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\device\dispatch/dispatch_reduce.cuh(361): error : class "std::iterator_traits<thrust::cuda_cub::pointer<const vtkm::Int32>>" has no member "value_type"
detected during:
processing of template argument list for "thrust::cuda_cub::cub::DispatchReduce" based on template arguments <thrust::cuda_cub::pointer<const vtkm::Int32>, int *, OffsetT, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>
C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v9.2/include\thrust/system/cuda/detail/cub/device/device_reduce.cuh(162): here
instantiation of "cudaError_t thrust::cuda_cub::cub::DeviceReduce::Reduce(void *, size_t &, InputIteratorT, OutputIteratorT, int, ReductionOpT, T, cudaStream_t, __nv_bool) [with InputIteratorT=thrust::cuda_cub::pointer<const vtkm::Int32>, OutputIteratorT=int *, ReductionOpT=vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>, T=int]"
C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v9.2/include\thrust/system/cuda/detail/reduce.h(950): here
instantiation of "T thrust::cuda_cub::reduce_n(thrust::cuda_cub::execution_policy<Derived> &, InputIt, Size, T, BinaryOp) [with Derived=thrust::cuda_cub::execute_on_stream, InputIt=thrust::cuda_cub::pointer<const vtkm::Int32>, Size=ptrdiff_t, T=int, BinaryOp=vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>]"
C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v9.2/include\thrust/system/cuda/detail/reduce.h(1010): here
instantiation of "T thrust::cuda_cub::reduce(thrust::cuda_cub::execution_policy<Derived> &, InputIt, InputIt, T, BinaryOp) [with Derived=thrust::cuda_cub::execute_on_stream, InputIt=thrust::cuda_cub::pointer<const vtkm::Int32>, T=int, BinaryOp=vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>]"
C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v9.2/include\thrust/detail/reduce.inl(71): here
instantiation of "T thrust::reduce(const thrust::detail::execution_policy_base<DerivedPolicy> &, InputIterator, InputIterator, T, BinaryFunction) [with DerivedPolicy=thrust::cuda_cub::execute_on_stream, InputIterator=thrust::cuda_cub::pointer<const vtkm::Int32>, T=int, BinaryFunction=vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/cont/cuda/internal/DeviceAdapterAlgorithmThrust.h(343): here
[ 8 instantiation contexts not shown ]
instantiation of "void vtkm::detail::ListForEachImpl(Functor &&, brigand::list<T1, T2, T3>) [with Functor=vtkm::cont::detail::TryExecuteImpl<vtkm::filter::detail::FilterDataSetPrepareForExecutionFunctor<vtkm::filter::ExternalFaces, vtkmInputFilterPolicy>> &, T1=vtkm::cont::DeviceAdapterTagCuda, T2=vtkm::cont::DeviceAdapterTagTBB, T3=vtkm::cont::DeviceAdapterTagSerial]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/ListTag.h(92): here
instantiation of "void vtkm::ListForEach(Functor &&, ListTag) [with Functor=vtkm::cont::detail::TryExecuteImpl<vtkm::filter::detail::FilterDataSetPrepareForExecutionFunctor<vtkm::filter::ExternalFaces, vtkmInputFilterPolicy>> &, ListTag=vtkmInputFilterPolicy::DeviceAdapterList]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/cont/TryExecute.h(175): here
instantiation of "__nv_bool vtkm::cont::TryExecute(Functor &, vtkm::cont::RuntimeDeviceTracker, DeviceList) [with Functor=vtkm::filter::detail::FilterDataSetPrepareForExecutionFunctor<vtkm::filter::ExternalFaces, vtkmInputFilterPolicy>, DeviceList=vtkmInputFilterPolicy::DeviceAdapterList]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/filter/FilterDataSet.hxx(116): here
instantiation of "vtkm::filter::Result vtkm::filter::FilterDataSet<Derived>::PrepareForExecution(const vtkm::cont::DataSet &, const vtkm::filter::PolicyBase<DerivedPolicy> &) [with Derived=vtkm::filter::ExternalFaces, DerivedPolicy=vtkmInputFilterPolicy]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/filter/FilterDataSet.hxx(70): here
instantiation of "vtkm::filter::Result vtkm::filter::FilterDataSet<Derived>::Execute(const vtkm::cont::DataSet &, const vtkm::filter::PolicyBase<DerivedPolicy> &) [with Derived=vtkm::filter::ExternalFaces, DerivedPolicy=vtkmInputFilterPolicy]"
c:\users\administrator\downloads\vtk-8.1.1\accelerators\vtkm\vtkmExternalFaces.cxx(133): here
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\device\dispatch\../../agent/agent_reduce.cuh(107): error : class "std::iterator_traits<thrust::cuda_cub::pointer<const vtkm::Int32>>" has no member "value_type"
detected during:
instantiation of class "thrust::cuda_cub::cub::AgentReduce<AgentReducePolicy, InputIteratorT, OutputIteratorT, OffsetT, ReductionOp> [with AgentReducePolicy=thrust::cuda_cub::cub::AgentReducePolicy<256, 16, 4, thrust::cuda_cub::cub::BLOCK_REDUCE_WARP_REDUCTIONS, thrust::cuda_cub::cub::LOAD_LDG>, InputIteratorT=thrust::cuda_cub::pointer<const vtkm::Int32>, OutputIteratorT=int *, OffsetT=int, ReductionOp=vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>]"
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\device\dispatch/dispatch_reduce.cuh(130): here
instantiation of "void thrust::cuda_cub::cub::DeviceReduceSingleTileKernel<ChainedPolicyT,InputIteratorT,OutputIteratorT,OffsetT,ReductionOpT,OutputT>(InputIteratorT, OutputIteratorT, OffsetT, ReductionOpT, OutputT) [with ChainedPolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy600, InputIteratorT=thrust::cuda_cub::pointer<const vtkm::Int32>, OutputIteratorT=int *, OffsetT=int, ReductionOpT=vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>, OutputT=std::remove_cv_t<int>]"
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\device\dispatch/dispatch_reduce.cuh(599): here
instantiation of "cudaError_t thrust::cuda_cub::cub::DispatchReduce<InputIteratorT, OutputIteratorT, OffsetT, ReductionOpT, OutputT>::Invoke<ActivePolicyT>() [with InputIteratorT=thrust::cuda_cub::pointer<const vtkm::Int32>, OutputIteratorT=int *, OffsetT=int, ReductionOpT=vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>, OutputT=std::remove_cv_t<int>, ActivePolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy130]"
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\iterator\../util_device.cuh(332): here
instantiation of "cudaError_t thrust::cuda_cub::cub::ChainedPolicy<PTX_VERSION, PolicyT, PolicyT>::Invoke(int, FunctorT &) [with PTX_VERSION=130, PolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy130, FunctorT=thrust::cuda_cub::cub::DispatchReduce<thrust::cuda_cub::pointer<const vtkm::Int32>, int *, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>, std::remove_cv_t<int>>]"
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\iterator\../util_device.cuh(315): here
instantiation of "cudaError_t thrust::cuda_cub::cub::ChainedPolicy<PTX_VERSION, PolicyT, PrevPolicyT>::Invoke(int, FunctorT &) [with PTX_VERSION=200, PolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy200, PrevPolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy130, FunctorT=thrust::cuda_cub::cub::DispatchReduce<thrust::cuda_cub::pointer<const vtkm::Int32>, int *, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>, std::remove_cv_t<int>>]"
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\iterator\../util_device.cuh(315): here
[ 16 instantiation contexts not shown ]
instantiation of "void vtkm::detail::ListForEachImpl(Functor &&, brigand::list<T1, T2, T3>) [with Functor=vtkm::cont::detail::TryExecuteImpl<vtkm::filter::detail::FilterDataSetPrepareForExecutionFunctor<vtkm::filter::ExternalFaces, vtkmInputFilterPolicy>> &, T1=vtkm::cont::DeviceAdapterTagCuda, T2=vtkm::cont::DeviceAdapterTagTBB, T3=vtkm::cont::DeviceAdapterTagSerial]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/ListTag.h(92): here
instantiation of "void vtkm::ListForEach(Functor &&, ListTag) [with Functor=vtkm::cont::detail::TryExecuteImpl<vtkm::filter::detail::FilterDataSetPrepareForExecutionFunctor<vtkm::filter::ExternalFaces, vtkmInputFilterPolicy>> &, ListTag=vtkmInputFilterPolicy::DeviceAdapterList]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/cont/TryExecute.h(175): here
instantiation of "__nv_bool vtkm::cont::TryExecute(Functor &, vtkm::cont::RuntimeDeviceTracker, DeviceList) [with Functor=vtkm::filter::detail::FilterDataSetPrepareForExecutionFunctor<vtkm::filter::ExternalFaces, vtkmInputFilterPolicy>, DeviceList=vtkmInputFilterPolicy::DeviceAdapterList]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/filter/FilterDataSet.hxx(116): here
instantiation of "vtkm::filter::Result vtkm::filter::FilterDataSet<Derived>::PrepareForExecution(const vtkm::cont::DataSet &, const vtkm::filter::PolicyBase<DerivedPolicy> &) [with Derived=vtkm::filter::ExternalFaces, DerivedPolicy=vtkmInputFilterPolicy]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/filter/FilterDataSet.hxx(70): here
instantiation of "vtkm::filter::Result vtkm::filter::FilterDataSet<Derived>::Execute(const vtkm::cont::DataSet &, const vtkm::filter::PolicyBase<DerivedPolicy> &) [with Derived=vtkm::filter::ExternalFaces, DerivedPolicy=vtkmInputFilterPolicy]"
c:\users\administrator\downloads\vtk-8.1.1\accelerators\vtkm\vtkmExternalFaces.cxx(133): here
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\device\dispatch\../../agent/agent_reduce.cuh(111): error : class "std::iterator_traits<thrust::cuda_cub::pointer<const vtkm::Int32>>" has no member "value_type"
detected during:
instantiation of class "thrust::cuda_cub::cub::AgentReduce<AgentReducePolicy, InputIteratorT, OutputIteratorT, OffsetT, ReductionOp> [with AgentReducePolicy=thrust::cuda_cub::cub::AgentReducePolicy<256, 16, 4, thrust::cuda_cub::cub::BLOCK_REDUCE_WARP_REDUCTIONS, thrust::cuda_cub::cub::LOAD_LDG>, InputIteratorT=thrust::cuda_cub::pointer<const vtkm::Int32>, OutputIteratorT=int *, OffsetT=int, ReductionOp=vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>]"
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\device\dispatch/dispatch_reduce.cuh(130): here
instantiation of "void thrust::cuda_cub::cub::DeviceReduceSingleTileKernel<ChainedPolicyT,InputIteratorT,OutputIteratorT,OffsetT,ReductionOpT,OutputT>(InputIteratorT, OutputIteratorT, OffsetT, ReductionOpT, OutputT) [with ChainedPolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy600, InputIteratorT=thrust::cuda_cub::pointer<const vtkm::Int32>, OutputIteratorT=int *, OffsetT=int, ReductionOpT=vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>, OutputT=std::remove_cv_t<int>]"
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\device\dispatch/dispatch_reduce.cuh(599): here
instantiation of "cudaError_t thrust::cuda_cub::cub::DispatchReduce<InputIteratorT, OutputIteratorT, OffsetT, ReductionOpT, OutputT>::Invoke<ActivePolicyT>() [with InputIteratorT=thrust::cuda_cub::pointer<const vtkm::Int32>, OutputIteratorT=int *, OffsetT=int, ReductionOpT=vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>, OutputT=std::remove_cv_t<int>, ActivePolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy130]"
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\iterator\../util_device.cuh(332): here
instantiation of "cudaError_t thrust::cuda_cub::cub::ChainedPolicy<PTX_VERSION, PolicyT, PolicyT>::Invoke(int, FunctorT &) [with PTX_VERSION=130, PolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy130, FunctorT=thrust::cuda_cub::cub::DispatchReduce<thrust::cuda_cub::pointer<const vtkm::Int32>, int *, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>, std::remove_cv_t<int>>]"
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\iterator\../util_device.cuh(315): here
instantiation of "cudaError_t thrust::cuda_cub::cub::ChainedPolicy<PTX_VERSION, PolicyT, PrevPolicyT>::Invoke(int, FunctorT &) [with PTX_VERSION=200, PolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy200, PrevPolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy130, FunctorT=thrust::cuda_cub::cub::DispatchReduce<thrust::cuda_cub::pointer<const vtkm::Int32>, int *, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>, std::remove_cv_t<int>>]"
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\iterator\../util_device.cuh(315): here
[ 16 instantiation contexts not shown ]
instantiation of "void vtkm::detail::ListForEachImpl(Functor &&, brigand::list<T1, T2, T3>) [with Functor=vtkm::cont::detail::TryExecuteImpl<vtkm::filter::detail::FilterDataSetPrepareForExecutionFunctor<vtkm::filter::ExternalFaces, vtkmInputFilterPolicy>> &, T1=vtkm::cont::DeviceAdapterTagCuda, T2=vtkm::cont::DeviceAdapterTagTBB, T3=vtkm::cont::DeviceAdapterTagSerial]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/ListTag.h(92): here
instantiation of "void vtkm::ListForEach(Functor &&, ListTag) [with Functor=vtkm::cont::detail::TryExecuteImpl<vtkm::filter::detail::FilterDataSetPrepareForExecutionFunctor<vtkm::filter::ExternalFaces, vtkmInputFilterPolicy>> &, ListTag=vtkmInputFilterPolicy::DeviceAdapterList]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/cont/TryExecute.h(175): here
instantiation of "__nv_bool vtkm::cont::TryExecute(Functor &, vtkm::cont::RuntimeDeviceTracker, DeviceList) [with Functor=vtkm::filter::detail::FilterDataSetPrepareForExecutionFunctor<vtkm::filter::ExternalFaces, vtkmInputFilterPolicy>, DeviceList=vtkmInputFilterPolicy::DeviceAdapterList]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/filter/FilterDataSet.hxx(116): here
instantiation of "vtkm::filter::Result vtkm::filter::FilterDataSet<Derived>::PrepareForExecution(const vtkm::cont::DataSet &, const vtkm::filter::PolicyBase<DerivedPolicy> &) [with Derived=vtkm::filter::ExternalFaces, DerivedPolicy=vtkmInputFilterPolicy]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/filter/FilterDataSet.hxx(70): here
instantiation of "vtkm::filter::Result vtkm::filter::FilterDataSet<Derived>::Execute(const vtkm::cont::DataSet &, const vtkm::filter::PolicyBase<DerivedPolicy> &) [with Derived=vtkm::filter::ExternalFaces, DerivedPolicy=vtkmInputFilterPolicy]"
c:\users\administrator\downloads\vtk-8.1.1\accelerators\vtkm\vtkmExternalFaces.cxx(133): here
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\device\dispatch/dispatch_reduce.cuh(78): error : class "std::iterator_traits<thrust::cuda_cub::pointer<const vtkm::Int32>>" has no member "value_type"
detected during:
instantiation of "void thrust::cuda_cub::cub::DeviceReduceKernel<ChainedPolicyT,InputIteratorT,OutputIteratorT,OffsetT,ReductionOpT>(InputIteratorT, OutputIteratorT, OffsetT, thrust::cuda_cub::cub::GridEvenShare<OffsetT>, ReductionOpT) [with ChainedPolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy600, InputIteratorT=thrust::cuda_cub::pointer<const vtkm::Int32>, OutputIteratorT=std::remove_cv_t<int> *, OffsetT=int, ReductionOpT=vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>]"
(606): here
instantiation of "cudaError_t thrust::cuda_cub::cub::DispatchReduce<InputIteratorT, OutputIteratorT, OffsetT, ReductionOpT, OutputT>::Invoke<ActivePolicyT>() [with InputIteratorT=thrust::cuda_cub::pointer<const vtkm::Int32>, OutputIteratorT=int *, OffsetT=int, ReductionOpT=vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>, OutputT=std::remove_cv_t<int>, ActivePolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy130]"
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\iterator\../util_device.cuh(332): here
instantiation of "cudaError_t thrust::cuda_cub::cub::ChainedPolicy<PTX_VERSION, PolicyT, PolicyT>::Invoke(int, FunctorT &) [with PTX_VERSION=130, PolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy130, FunctorT=thrust::cuda_cub::cub::DispatchReduce<thrust::cuda_cub::pointer<const vtkm::Int32>, int *, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>, std::remove_cv_t<int>>]"
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\iterator\../util_device.cuh(315): here
instantiation of "cudaError_t thrust::cuda_cub::cub::ChainedPolicy<PTX_VERSION, PolicyT, PrevPolicyT>::Invoke(int, FunctorT &) [with PTX_VERSION=200, PolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy200, PrevPolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy130, FunctorT=thrust::cuda_cub::cub::DispatchReduce<thrust::cuda_cub::pointer<const vtkm::Int32>, int *, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>, std::remove_cv_t<int>>]"
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\iterator\../util_device.cuh(315): here
instantiation of "cudaError_t thrust::cuda_cub::cub::ChainedPolicy<PTX_VERSION, PolicyT, PrevPolicyT>::Invoke(int, FunctorT &) [with PTX_VERSION=300, PolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy300, PrevPolicyT=thrust::cuda_cub::cub::DeviceReducePolicy<std::remove_cv_t<int>, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>>::Policy200, FunctorT=thrust::cuda_cub::cub::DispatchReduce<thrust::cuda_cub::pointer<const vtkm::Int32>, int *, int, vtkm::exec::cuda::internal::WrappedBinaryOperator<int, vtkm::Sum>, std::remove_cv_t<int>>]"
c:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\thrust\system\cuda\detail\cub\iterator\../util_device.cuh(315): here
[ 15 instantiation contexts not shown ]
instantiation of "void vtkm::detail::ListForEachImpl(Functor &&, brigand::list<T1, T2, T3>) [with Functor=vtkm::cont::detail::TryExecuteImpl<vtkm::filter::detail::FilterDataSetPrepareForExecutionFunctor<vtkm::filter::ExternalFaces, vtkmInputFilterPolicy>> &, T1=vtkm::cont::DeviceAdapterTagCuda, T2=vtkm::cont::DeviceAdapterTagTBB, T3=vtkm::cont::DeviceAdapterTagSerial]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/ListTag.h(92): here
instantiation of "void vtkm::ListForEach(Functor &&, ListTag) [with Functor=vtkm::cont::detail::TryExecuteImpl<vtkm::filter::detail::FilterDataSetPrepareForExecutionFunctor<vtkm::filter::ExternalFaces, vtkmInputFilterPolicy>> &, ListTag=vtkmInputFilterPolicy::DeviceAdapterList]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/cont/TryExecute.h(175): here
instantiation of "__nv_bool vtkm::cont::TryExecute(Functor &, vtkm::cont::RuntimeDeviceTracker, DeviceList) [with Functor=vtkm::filter::detail::FilterDataSetPrepareForExecutionFunctor<vtkm::filter::ExternalFaces, vtkmInputFilterPolicy>, DeviceList=vtkmInputFilterPolicy::DeviceAdapterList]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/filter/FilterDataSet.hxx(116): here
instantiation of "vtkm::filter::Result vtkm::filter::FilterDataSet<Derived>::PrepareForExecution(const vtkm::cont::DataSet &, const vtkm::filter::PolicyBase<DerivedPolicy> &) [with Derived=vtkm::filter::ExternalFaces, DerivedPolicy=vtkmInputFilterPolicy]"
C:/Users/Administrator/Downloads/VTK-8.1.1/ThirdParty/vtkm/vtk-m\vtkm/filter/FilterDataSet.hxx(70): here
instantiation of "vtkm::filter::Result vtkm::filter::FilterDataSet<Derived>::Execute(const vtkm::cont::DataSet &, const vtkm::filter::PolicyBase<DerivedPolicy> &) [with Derived=vtkm::filter::ExternalFaces, DerivedPolicy=vtkmInputFilterPolicy]"
c:\users\administrator\downloads\vtk-8.1.1\accelerators\vtkm\vtkmExternalFaces.cxx(133): here
...
4 errors detected in the compilation of "C:/Users/ADMINI~1/AppData/Local/Temp/tmpxft_00000bc0_00000000-14_vtkmExternalFaces.compute_70.cpp1.ii".
vtkmExternalFaces.cu
CMake Error at vtkAcceleratorsVTKmCuda_generated_vtkmExternalFaces.cu.obj.Release.cmake:279 (message):
Error generating file
C:/Users/Administrator/Downloads/VTK-8.1.1/build/Accelerators/Vtkm/CMakeFiles/vtkAcceleratorsVTKmCuda.dir//Release/vtkAcceleratorsVTKmCuda_generated_vtkmExternalFaces.cu.obj
Done building project "vtkAcceleratorsVTKmCuda.vcxproj" -- FAILED.
```
I will appreciate if someone can help me to solve this issue. Thanks in advance!Robert MaynardRobert Maynardhttps://gitlab.kitware.com/vtk/vtk/-/issues/17412Consider using -dumpversion instead of --version for detecting compiler version2019-01-09T15:35:09-05:00Nehal J WaniConsider using -dumpversion instead of --version for detecting compiler versionThe compiler being used by me on --version, throws the following output:
```
x86_64-conda_cos6-linux-gnu-cc (crosstool-NG 1.23.0.449-a04d0) 7.3.0 ...The compiler being used by me on --version, throws the following output:
```
x86_64-conda_cos6-linux-gnu-cc (crosstool-NG 1.23.0.449-a04d0) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```
The regex parsing in the macro `_vtk_test_compiler_hidden_visibility` in `CMake/VTKGenerateExportHeader.cmake` fails, because then it sets `gcc_version` to `3.0.449` instead of `7.3.0` and makes the assumption that the compiler is too old and ends up generating header files with no (blank) values for `DEFINE_EXPORT`, `DEFINE_IMPORT` and `DEFINE_NO_EXPORT`
Why use --version, instead of just -dumpversion or `CMAKE_CXX_COMPILER_VERSION` ?Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17432Error: Building CXX object VTK/GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/Q...2019-04-18T09:44:09-04:00Chong LInError: Building CXX object VTK/GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/QVTKOpenGLNativeWidget.cxx.oWhen I building my paraview, the following errors happened, I can’t solve it. Anybody else have met the similar errors? Could you give me some suggestions? Thank you very much.
```
zhou@zhou-virtual-machine:~$ cd paraview_build/
zhou@z...When I building my paraview, the following errors happened, I can’t solve it. Anybody else have met the similar errors? Could you give me some suggestions? Thank you very much.
```
zhou@zhou-virtual-machine:~$ cd paraview_build/
zhou@zhou-virtual-machine:~/paraview_build$ make
[ 8%] Built target ParaViewData
[ 19%] Built target VTKData
[ 19%] Built target kwiml_test
[ 19%] Built target vtksys
[ 19%] Built target vtkWrappingTools
[ 19%] Built target vtkWrapHierarchy
[ 19%] Built target vtkCommonCoreHierarchy
[ 20%] Built target vtkCommonCore
[ 20%] Built target vtkCommonMathHierarchy
[ 20%] Built target vtkCommonMath
[ 20%] Built target vtkCommonMiscHierarchy
[ 20%] Built target vtkCommonMisc
[ 20%] Built target vtkCommonSystemHierarchy
[ 20%] Built target vtkCommonSystem
[ 20%] Built target vtkCommonTransformsHierarchy
[ 20%] Built target vtkCommonTransforms
[ 20%] Built target vtkCommonDataModelHierarchy
[ 21%] Built target vtkCommonDataModel
[ 21%] Built target vtkCommonExecutionModelHierarchy
[ 21%] Built target vtkCommonExecutionModel
[ 21%] Built target vtkFiltersCoreHierarchy
[ 22%] Built target vtkFiltersCore
[ 22%] Built target vtkCommonComputationalGeometryHierarchy
[ 22%] Built target vtkCommonComputationalGeometry
[ 22%] Built target vtkFiltersGeneralHierarchy
[ 23%] Built target vtkFiltersGeneral
[ 23%] Built target vtkImagingCoreHierarchy
[ 23%] Built target vtkImagingCore
[ 23%] Built target vtkImagingFourierHierarchy
[ 23%] Built target vtkImagingFourier
[ 23%] Built target vtkFiltersStatisticsHierarchy
[ 23%] Built target vtkFiltersStatistics
[ 23%] Built target vtkFiltersExtractionHierarchy
[ 23%] Built target vtkFiltersExtraction
[ 23%] Built target vtkFiltersSourcesHierarchy
[ 23%] Built target vtkFiltersSources
[ 23%] Built target vtkCommonColorHierarchy
[ 23%] Built target vtkCommonColor
[ 23%] Built target vtkFiltersGeometryHierarchy
[ 23%] Built target vtkFiltersGeometry
[ 23%] Built target vtkRenderingCoreHierarchy
[ 24%] Built target vtkRenderingCore
[ 24%] Built target vtkInteractionStyleHierarchy
[ 25%] Built target vtkInteractionStyle
[ 25%] Built target vtkglew
[ 25%] Built target vtkRenderingOpenGL2Hierarchy
[ 25%] Built target vtkRenderingOpenGL2
[ 25%] Built target vtkProbeOpenGLVersion
[ 25%] Built target vtkProbeOpenGLVersion-launcher
Scanning dependencies of target vtkGUISupportQt
[ 25%] Building CXX object VTK/GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/QVTKOpenGLNativeWidget.cxx.o
/home/zhou/paraview/VTK/GUISupport/Qt/QVTKOpenGLNativeWidget.cxx: In member function ‘void QVTKOpenGLNativeWidget::recreateFBO()’:
/home/zhou/paraview/VTK/GUISupport/Qt/QVTKOpenGLNativeWidget.cxx:386:52: error: ‘GL_RENDERBUFFER_SAMPLES’ was not declared in this scope
f->glGetRenderbufferParameteriv(GL_RENDERBUFFER, GL_RENDERBUFFER_SAMPLES, &samples);
^
/home/zhou/paraview/VTK/GUISupport/Qt/QVTKOpenGLNativeWidget.cxx: In member function ‘virtual void QVTKOpenGLNativeWidget::paintGL()’:
/home/zhou/paraview/VTK/GUISupport/Qt/QVTKOpenGLNativeWidget.cxx:526:3: error: ‘QOpenGLFunctions_3_2_Core’ was not declared in this scope
QOpenGLFunctions_3_2_Core* f =
^
/home/zhou/paraview/VTK/GUISupport/Qt/QVTKOpenGLNativeWidget.cxx:526:30: error: ‘f’ was not declared in this scope
QOpenGLFunctions_3_2_Core* f =
^
/home/zhou/paraview/VTK/GUISupport/Qt/QVTKOpenGLNativeWidget.cxx:527:56: error: the value of ‘QOpenGLFunctions_3_2_Core’ is not usable in a constant expression
QOpenGLContext::currentContext()->versionFunctions<QOpenGLFunctions_3_2_Core>();
^
/home/zhou/paraview/VTK/GUISupport/Qt/QVTKOpenGLNativeWidget.cxx:526:3: note: ‘QOpenGLFunctions_3_2_Core’ was not declared ‘constexpr’
QOpenGLFunctions_3_2_Core* f =
^
/home/zhou/paraview/VTK/GUISupport/Qt/QVTKOpenGLNativeWidget.cxx:527:83: error: no matching function for call to ‘QOpenGLContext::versionFunctions()’
QOpenGLContext::currentContext()->versionFunctions<QOpenGLFunctions_3_2_Core>();
^
/home/zhou/paraview/VTK/GUISupport/Qt/QVTKOpenGLNativeWidget.cxx:527:83: note: candidate is:
In file included from /home/zhou/Qt/5.11.2/android_armv7/include/QtGui/QOpenGLContext:1:0,
from /home/zhou/paraview/VTK/GUISupport/Qt/QVTKOpenGLNativeWidget.cxx:20:
/home/zhou/Qt/5.11.2/android_armv7/include/QtGui/qopenglcontext.h:194:11: note: template<class TYPE> TYPE* QOpenGLContext::versionFunctions() const
TYPE *versionFunctions() const
^
/home/zhou/Qt/5.11.2/android_armv7/include/QtGui/qopenglcontext.h:194:11: note: template argument deduction/substitution failed:
/home/zhou/paraview/VTK/GUISupport/Qt/QVTKOpenGLNativeWidget.cxx:532:26: error: ‘GL_DRAW_FRAMEBUFFER’ was not declared in this scope
f->glBindFramebuffer(GL_DRAW_FRAMEBUFFER, this->defaultFramebufferObject());
^
/home/zhou/paraview/VTK/GUISupport/Qt/QVTKOpenGLNativeWidget.cxx:535:26: error: ‘GL_READ_FRAMEBUFFER’ was not declared in this scope
f->glBindFramebuffer(GL_READ_FRAMEBUFFER, this->FBO->handle());
^
make[2]: *** [VTK/GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/QVTKOpenGLNativeWidget.cxx.o] Error 1
make[1]: *** [VTK/GUISupport/Qt/CMakeFiles/vtkGUISupportQt.dir/all] Error 2
make: *** [all] Error 2
```
https://gitlab.kitware.com/vtk/vtk/-/issues/17433Build Errors on Windows, VS 20172019-04-18T09:43:10-04:00Matt LeottaBuild Errors on Windows, VS 2017I'm getting errors building VTK on Windows 10 in Visual Studio 2017. I get several copies of error similar to this:
```
8>CUSTOMBUILD : CMake error : Could not open file for write in copy operation C:/Build/maptk-sbnc/external/fletch-bu...I'm getting errors building VTK on Windows 10 in Visual Studio 2017. I get several copies of error similar to this:
```
8>CUSTOMBUILD : CMake error : Could not open file for write in copy operation C:/Build/maptk-sbnc/external/fletch-build/build/src/VTK-build/C:/Build/maptk-sbnc/external/fletch-build/install/lib/cmake/vtk-8.2/Modules/vtkkwiml.cmake.tmp
8>CUSTOMBUILD : CMake error : : System Error: Invalid argument
8>CMake Error at CMake/vtkModuleMacros.cmake:337 (configure_file):
8> configure_file Problem configuring file
8>Call Stack (most recent call first):
8> Utilities/KWIML/CMakeLists.txt:5 (vtk_module_export_info)
```
Note VTK is being built as part of Fletch, which specifies a custom install directory. It appears to be caused by changes in 2ef6c770. Apparently replacing `lib` with `${CMAKE_INSTALL_LIBDIR}` is problematic in cases where `${CMAKE_INSTALL_LIBDIR}` is an absolute path (at least on Windows).https://gitlab.kitware.com/vtk/vtk/-/issues/17451VTK w/ TBB missing TBB config info in CMake2019-04-18T09:52:14-04:00IsaiahVTK w/ TBB missing TBB config info in CMakeVTK built against TBB exposes several TBB includes (`{atomic,blocked_range,parallel_for}.h`), in what are -- as far as I can tell -- public headers: `vtkAtomic.h` and `vtkSMPThreadLocal.h` (also `vtkSMPToolsInternal.h`, but that's not pu...VTK built against TBB exposes several TBB includes (`{atomic,blocked_range,parallel_for}.h`), in what are -- as far as I can tell -- public headers: `vtkAtomic.h` and `vtkSMPThreadLocal.h` (also `vtkSMPToolsInternal.h`, but that's not public).
This appears to mean that any program linked against VTK w/TBB needs to make TBB headers available. However, I don't see a way to discover that fact using VTKConfig.cmake, except by grep'ing the `INTERFACE_LINK_LIBRARIES` for libtbb.
Given the error below, it's unclear how I would determine, from VTK CMake config files, that ITK needs to pass TBB header paths to ITKVtkGlue (assuming ITK was also built with TBB -- otherwise it should probably raise an error).
<details>
<summary>example error in ITKVtkGlue (click to expand)</summary>
```
[100%] Built target ITKIOMesh
In file included from /bp/_h_env/include/vtk-8.1/vtkAtomicTypes.h:18:0,
from /bp/_h_env/include/vtk-8.1/vtkObjectBase.h:54,
from /bp/_h_env/include/vtk-8.1/vtkObject.h:45,
from /bp/_h_env/include/vtk-8.1/vtkVersion.h:32,
from /bp/work/build/ITKv5/Modules/Bridge/VtkGlue/src/QuickView.cxx:25:
/bp/_h_env/include/vtk-8.1/vtkAtomic.h:28:10: fatal error: tbb/atomic.h: No such file or directory
#include <tbb/atomic.h>
^~~~~~~~~~~~~~
compilation terminated.
[100%] Built target ITKIOMesh-all
make[2]: *** [Modules/Bridge/VtkGlue/src/CMakeFiles/ITKVtkGlue.dir/QuickView.cxx.o] Error 1
make[1]: *** [Modules/Bridge/VtkGlue/src/CMakeFiles/ITKVtkGlue.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
```
</details>
<br>
related: https://gitlab.kitware.com/vtk/vtk/issues/16867Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17474VTK_BUILD_TESTING 3 states are insufficient2019-01-09T11:53:58-05:00Robert MaynardVTK_BUILD_TESTING 3 states are insufficientCurrent `VTK_BUILD_TESTING` has the following three states:
1. 'ON' - try to enable all modules that are part of TEST_DEPENDS of any module that is default. This means that on machines without MPI enabled the configuration errors out si...Current `VTK_BUILD_TESTING` has the following three states:
1. 'ON' - try to enable all modules that are part of TEST_DEPENDS of any module that is default. This means that on machines without MPI enabled the configuration errors out since 'VTK::ParallelMPI' is not enabled.
2. 'OFF' - this works as expected
3. 'DEFAULT' - this means that only modules that are currently enabled will be enabled. So for example if you enable `VTK::AcceleratorsVTKm` you will NOT get any tests unless you manually enable all of the following modules:
```
VTK::CommonSystem
VTK::FiltersSources
VTK::IOImage
VTK::IOLegacy
VTK::IOPLY
VTK::IOXML
VTK::ImagingHybrid
VTK::ImagingSources
VTK::InteractionStyle
VTK::RenderingFreeType
VTK::RenderingOpenGL2
VTK::RenderingVolumeOpenGL2
VTK::TestingCore
VTK::TestingRendering
```
If these modules are marked as `DEFAULT` they will not be enabled you have to force them to `YES` or `WANT`.
So what we need is the ability for a module to mark all TEST_DEPENDS as `WANT` so they become enabled if the system supports them.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17475VTK_GROUP_ENABLE_Rendering doesn't enable RenderingVolumeOpenGL22019-01-09T11:35:53-05:00Robert MaynardVTK_GROUP_ENABLE_Rendering doesn't enable RenderingVolumeOpenGL2On a clean build of VTK the `RenderingVolumeOpenGL2` is not enabled even though `RenderingOpenGL2` and `RenderingVolume` are.
```
make help | grep Rendering
... RenderingCore-hierarchy
... RenderingCore
... RenderingFreeType
... Render...On a clean build of VTK the `RenderingVolumeOpenGL2` is not enabled even though `RenderingOpenGL2` and `RenderingVolume` are.
```
make help | grep Rendering
... RenderingCore-hierarchy
... RenderingCore
... RenderingFreeType
... RenderingFreeType-hierarchy
... RenderingContext2D-hierarchy
... RenderingContext2D
... RenderingAnnotation-hierarchy
... RenderingAnnotation
... RenderingVolume-hierarchy
... RenderingVolume
... RenderingLabel
... RenderingLabel-hierarchy
... TestingRendering-hierarchy
... TestingRendering
... RenderingLOD
... RenderingLOD-hierarchy
... RenderingImage-hierarchy
... RenderingImage
... RenderingOpenGL2
... RenderingOpenGL2-hierarchy
... RenderingGL2PSOpenGL2
... RenderingGL2PSOpenGL2-hierarchy
... vtkRenderingLabelCxxTests
... vtkRenderingLODCxxTests
... vtkRenderingImageCxxTests
... vtkRenderingGL2PSOpenGL2CxxTests
... vtkRenderingAnnotationCxxTests
... vtkRenderingOpenGL2CxxTests
... vtkRenderingCoreCxxTests
```Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17476LNK4049 warnings when compiling kits on Windows2019-01-10T20:03:11-05:00Ben BoeckelLNK4049 warnings when compiling kits on WindowsOn Windows, there are warnings when compiling kits due to objects compiled with `__declspec(dllimport)` being linked into the same library as those which compiled it with `__declspec(dllexport)`. Should we just suppress these warnings? I...On Windows, there are warnings when compiling kits due to objects compiled with `__declspec(dllimport)` being linked into the same library as those which compiled it with `__declspec(dllexport)`. Should we just suppress these warnings? Is there some other way to handle symbol exporting for kits?
[Linker documentation](https://docs.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-warning-lnk4049?view=vs-2017)
Cc: @brad.king @robertmaynardBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17477Convert verdict to use an import script2022-03-04T08:42:07-05:00Ben BoeckelConvert verdict to use an import scriptVerdict has a repository at https://gitlab.kitware.com/verdict/verdict. VTK should import its copy based on code from that repository.Verdict has a repository at https://gitlab.kitware.com/verdict/verdict. VTK should import its copy based on code from that repository.Spiros TsalikisSpiros Tsalikishttps://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/17483C++14 deprecation macro support2021-04-14T16:12:44-04:00Ben BoeckelC++14 deprecation macro support`VTK_DEPRECATED` is `[[deprecated]]` in C++14 mode. However, this does not mix well with `__attribute__` for export macros. Compiler-specific export attributes may be required. This is best done as a fix to `GenerateExportHeader.cmake` a...`VTK_DEPRECATED` is `[[deprecated]]` in C++14 mode. However, this does not mix well with `__attribute__` for export macros. Compiler-specific export attributes may be required. This is best done as a fix to `GenerateExportHeader.cmake` and upstreamed to CMake (VTK can carry the patch though).
If export macros can't be fixed before 9.0, `[[deprecated]]` should not be used until it is.
Cc: @seanmBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17484windows_path.bat is incorrect2019-01-15T17:27:08-05:00Andrew Macleanwindows_path.bat is incorrect`lib` instead of `bin` is being specified and `/bin/Lib/site-packages` is not being added to `PYTHONPATH`.
This file should look something like this:
```
set PATH=<path to build>/bin;%PATH%
set PYTHONPATH=<path to build>/bin/Lib/site-pa...`lib` instead of `bin` is being specified and `/bin/Lib/site-packages` is not being added to `PYTHONPATH`.
This file should look something like this:
```
set PATH=<path to build>/bin;%PATH%
set PYTHONPATH=<path to build>/bin/Lib/site-packages;%PYTHONPATH%
```
Currently it looks like this:
```
set PATH=<path to build>/lib;%PATH%
set PYTHONPATH=;%PYTHONPATH%
```
Cc: @ben.boeckelBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17485Java Wrapping VTK 8.90 fails in Windows.2019-01-15T16:38:03-05:00Andrew MacleanJava Wrapping VTK 8.90 fails in Windows.It seems to work in Ubuntu 18.10 with a few warnings however it fails in Windows 10:
This is the first error:
```
vtkConvertSelectionDomainJava.cxx.obj : error LNK2019: unresolved external symbol vtkPassInputTypeAlgorithm_Typecast refere...It seems to work in Ubuntu 18.10 with a few warnings however it fails in Windows 10:
This is the first error:
```
vtkConvertSelectionDomainJava.cxx.obj : error LNK2019: unresolved external symbol vtkPassInputTypeAlgorithm_Typecast referenced in function vtkConvertSelectionDomain_Typecast
vtkDataRepresentationJava.cxx.obj : error LNK2001: unresolved external symbol vtkPassInputTypeAlgorithm_Typecast
vtkViewJava.cxx.obj : error LNK2019: unresolved external symbol vtkObject_Typecast referenced in function vtkView_Typecast
vtkViewThemeJava.cxx.obj : error LNK2001: unresolved external symbol vtkObject_Typecast
bin\vtkViewsCoreJava.dll : fatal error LNK1120: 2 unresolved externals
[500/7406] Building CXX object Wrapping\Java\CMakeFiles\vt...monCoreJava.dir\CMakeFiles\vtkTypeFloat64ArrayJava.cxx.obj
ninja: build stopped: subcommand failed.
```
Running `ninja -k 100`generates lots more errors.
Most of the errors (if not all) are related to `vtk*_Typecast` as above.
Finally:
```
warning: [options] bootstrap class path not set in conjunction with -source 6
warning: [options] source value 6 is obsolete and will be removed in a future release
warning: [options] target value 1.6 is obsolete and will be removed in a future release
warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
```
Setting Java Source/Target version to 1.9 (the highest I can set even though I am using Java 1.11) produces the same result with these warnings:
```
warning: [options] bootstrap class path not set in conjunction with -source 9
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
```
Cc: @ben.boeckelBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17488Illegal path characters in directory name on windows (running INSTALL with VS...2019-01-24T09:26:57-05:00TimoIllegal path characters in directory name on windows (running INSTALL with VS 2017)I'm trying to build and install the latest version of the master branch (commit e81e5e736ee039049aeeb7f9be6b5297599813a7 on github). I can build VTK itself but when I build the INSTALL project I get a cmake error:
> file cannot create d...I'm trying to build and install the latest version of the master branch (commit e81e5e736ee039049aeeb7f9be6b5297599813a7 on github). I can build VTK itself but when I build the INSTALL project I get a cmake error:
> file cannot create directory:
> C:/libs/VTK/share/licenses/VTK/VTK::kwiml. Maybe need administrative privileges.
The specified folder is not restricted so I don't need admin privileges. I assume the error comes from the "::" in the path as colon is an illegal path char on windows.
**Edit**
Can confirm. If I replace the double colon with an underscore the install build completes successfully.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17507vtkWrapPython must match the wrapped VTK's 64BIT_IDS option2019-01-28T10:01:41-05:00Ben BoeckelvtkWrapPython must match the wrapped VTK's 64BIT_IDS optionRight now, in `vtkWrapPythonOverload.c`, `VTK_USE_64BIT_IDS` is used to change the format character for `vtkIdType` based on `vtkWrapPython`'s compiled VTK. This means that when cross-compiling, the `vtkWrapPython` tool must agree with t...Right now, in `vtkWrapPythonOverload.c`, `VTK_USE_64BIT_IDS` is used to change the format character for `vtkIdType` based on `vtkWrapPython`'s compiled VTK. This means that when cross-compiling, the `vtkWrapPython` tool must agree with the target's `vtkIdType` size. It would be best if this could be deferred to the output source code so that the wrapper tools can be completely independent of their compilation environment.
Cc: @dgobbi @ken\-martin @brad.kingDavid GobbiDavid Gobbihttps://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/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/17518Cannot build on OS X with Kits enabled2019-02-04T08:50:01-05:00T.J. CoronaCannot build on OS X with Kits enabledLike the title says, I cannot build on OS X with Kits enabled. There doesn't seem to be any OS X dashboards testing ParaView master right now.
@ben.boeckel @utkarsh.ayachitLike the title says, I cannot build on OS X with Kits enabled. There doesn't seem to be any OS X dashboards testing ParaView master right now.
@ben.boeckel @utkarsh.ayachitBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17527[Module] VTK_BUILD_TESTING and BUILD_TESTING options available in ccmake or c...2019-03-05T04:38:04-05:00Mathieu Westphal (Kitware)[Module] VTK_BUILD_TESTING and BUILD_TESTING options available in ccmake or cmake-guiThere are two options available in ccmake and cmake-gui, `VTK_BUILD_TESTING` and `BUILD_TESTING`.
`BUILD_TESTING` should be hidden.
this bug is also present in ParaView.
@ben.boeckelThere are two options available in ccmake and cmake-gui, `VTK_BUILD_TESTING` and `BUILD_TESTING`.
`BUILD_TESTING` should be hidden.
this bug is also present in ParaView.
@ben.boeckelBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17544mpi4py compilation error with openMPI 4.02019-04-30T08:40:27-04:00Nicolas Vuaillempi4py compilation error with openMPI 4.0Archlinux has just bump openmpi to version 4.0. This version seems to remove some deprecated code, leading to this failure:
``` bash
In file included from /home/nicolas/ParaView/ParaView/VTK/ThirdParty/mpi4py/vtkmpi4py/src/MPI.c:4:
/hom...Archlinux has just bump openmpi to version 4.0. This version seems to remove some deprecated code, leading to this failure:
``` bash
In file included from /home/nicolas/ParaView/ParaView/VTK/ThirdParty/mpi4py/vtkmpi4py/src/MPI.c:4:
/home/nicolas/ParaView/ParaView/VTK/ThirdParty/mpi4py/vtkmpi4py/src/mpi4py.MPI.c: In function ‘__pyx_f_6mpi4py_3MPI_del_Datatype’:
/home/nicolas/ParaView/ParaView/VTK/ThirdParty/mpi4py/vtkmpi4py/src/mpi4py.MPI.c:15141:36: error: ‘MPI_UB’ undeclared (first use in this function); did you mean ‘MPI_IO’?
__pyx_t_1 = (((__pyx_v_ob[0]) == MPI_UB) != 0);
^~~~~~
MPI_IO
/home/nicolas/ParaView/ParaView/VTK/ThirdParty/mpi4py/vtkmpi4py/src/mpi4py.MPI.c:15141:36: note: each undeclared identifier is reported only once for each function it appears in
/home/nicolas/ParaView/ParaView/VTK/ThirdParty/mpi4py/vtkmpi4py/src/mpi4py.MPI.c:15154:36: error: ‘MPI_LB’ undeclared (first use in this function); did you mean ‘MPI_IO’?
__pyx_t_1 = (((__pyx_v_ob[0]) == MPI_LB) != 0);
^~~~~~
MPI_IO
```
Regarding this issue https://bitbucket.org/mpi4py/mpi4py/issues/115/cannot-build-against-openmpi-400#comment-49251364 this should be fixed in mpi4py upstream.9.0Mathieu Westphal (Kitware)Mathieu Westphal (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/17545CMake Configuration Errors With MSVC 2017 on Win10 If Python Wrapping Is Turn...2019-03-20T21:03:13-04:00Max ZeyenCMake Configuration Errors With MSVC 2017 on Win10 If Python Wrapping Is Turned OnIf VTK is built with `VTK_WRAP_PYTHON=ON`, the errors below occur for both Python 2 and 3 (latest release in both cases). All three can be traced back to `${VTK_PYTHON_SITE_PACKAGES_SUFFIX}`, which is set by `vtk_module_python_default_de...If VTK is built with `VTK_WRAP_PYTHON=ON`, the errors below occur for both Python 2 and 3 (latest release in both cases). All three can be traced back to `${VTK_PYTHON_SITE_PACKAGES_SUFFIX}`, which is set by `vtk_module_python_default_destination(VTK_PYTHON_SITE_PACKAGES_SUFFIX)` in VTK's main CMakeLists.txt. This command introduces the generator expression `$<CONFIGURATION>` if the selected generator supports multiple configuration targets (e.g. Visual Studio).
CMake configuration and generation steps work fine using Ninja with the MSVC compiler.
First, is compiling VTK with the MSVC2017 generator supported?
If so, is this an error in the VTK CMakeLists.txt or a bug in CMake (haven't found an issue related to this for CMake either)?
Error Messages:
```
CMake Error at ThirdParty/mpi4py/vtkmpi4py/src/CMakeLists.txt:15 (add_custom_command):
add_custom_command called with OUTPUT containing a "<". This character is
not allowed.
CMake Error: Could not open file for write in copy operation C:/Users/mzeyen/projects/vtk/build/bin/$<CONFIGURATION>/Lib/site-packages/vtkmodules/all.py.tmp
CMake Error: : System Error: Invalid argument
CMake Error at Wrapping/Python/CMakeLists.txt:55 (configure_file):
configure_file Problem configuring file
CMake Error at Wrapping/Python/CMakeLists.txt:104 (add_custom_command):
add_custom_command called with OUTPUT containing a "<". This character is
not allowed.
```9.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17603cmake: _vtk_module_write_import_prefix loops infinitely2019-05-16T10:23:17-04:00Julien Schuellercmake: _vtk_module_write_import_prefix loops infinitelythis function was introduced in !5020, CMake/vtkModule.cmake:~1580:
```
function (_vtk_module_write_import_prefix file destination)
file(APPEND "${file}"
"set(_vtk_module_import_prefix \"\${CMAKE_CURRENT_LIST_DIR}\")\n")
while (...this function was introduced in !5020, CMake/vtkModule.cmake:~1580:
```
function (_vtk_module_write_import_prefix file destination)
file(APPEND "${file}"
"set(_vtk_module_import_prefix \"\${CMAKE_CURRENT_LIST_DIR}\")\n")
while (destination)
get_filename_component(destination "${destination}" DIRECTORY)
file(APPEND "${file}"
"get_filename_component(_vtk_module_import_prefix \"\${_vtk_module_import_prefix}\" DIRECTORY)\n")
endwhile ()
endfunction ()
```
I found out it hangs using MinGW from Linux.
It keeps requesting the parent directory of the variable destination but destination is always "/".
```
destination=/usr/i686-w64-mingw32/lib/cmake/paraview-5.6
destination=/usr/i686-w64-mingw32/lib/cmake
destination=/usr/i686-w64-mingw32/lib
destination=/usr/i686-w64-mingw32
destination=/usr
destination=/
destination=/
destination=/
destination=/
...
```
cc @ben.boeckelBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17605fatal error: vtk_hdf5.h: No such file or directory2019-05-20T09:53:37-04:00Julien Schuellerfatal error: vtk_hdf5.h: No such file or directoryI'm compiling vtk master with mingw from linux with hdf5 installed (hdf5 has to be patched to build with mingw) and it is not detected correctly:
```
-- Looking for H5free_memory
-- Looking for H5free_memory - not found
-- Looking for H5...I'm compiling vtk master with mingw from linux with hdf5 installed (hdf5 has to be patched to build with mingw) and it is not detected correctly:
```
-- Looking for H5free_memory
-- Looking for H5free_memory - not found
-- Looking for H5Pset_all_coll_metadata_ops
-- Looking for H5Pset_all_coll_metadata_ops - not found
-- Looking for H5Pset_libver_bounds
-- Looking for H5Pset_libver_bounds - not found
-- Looking for HDF5_PARALLEL
-- Looking for HDF5_PARALLEL - not found
```
Looking at build-i686-w64-mingw32/CMakeFiles/CMakeError.log:
```
build-i686-w64-mingw32/CMakeFiles/CMakeTmp/CheckSymbolExists.c:2:10: fatal error: vtk_hdf5.h: No such file or directory
```
Now, if I set CMAKE_REQUIRED_INCLUDES in ThirdParty/netcdf/vtknetcdf/CMakeLists.txt:
```
set(CMAKE_REQUIRED_INCLUDES ${CMAKE_BINARY_DIR}/ThirdParty/hdf5/;${CMAKE_SOURCE_DIR}/ThirdParty/hdf5/)
set(HAVE_HDF5_H 1)
check_symbol_exists("H5free_memory" "vtk_hdf5.h" HDF5_HAS_H5FREE)
check_symbol_exists("H5Pset_all_coll_metadata_ops" "vtk_hdf5.h" H5PSET_ALL_COLL_METADATA_OPS)
check_symbol_exists("H5Pset_libver_bounds" "vtk_hdf5.h" HDF5_HAS_LIBVER_BOUNDS)
check_symbol_exists("HDF5_PARALLEL" "vtk_hdf5.h" HDF5_PARALLEL)
```
cmake finds my hdf5 libs:
```
-- Looking for H5free_memory
-- Looking for H5free_memory - found
-- Looking for H5Pset_all_coll_metadata_ops
-- Looking for H5Pset_all_coll_metadata_ops - not found
-- Looking for H5Pset_libver_bounds
-- Looking for H5Pset_libver_bounds - found
-- Looking for HDF5_PARALLEL
-- Looking for HDF5_PARALLEL - not found
```
cc @ben.boeckel
Bonus question: it seems VTK_USE_SYSTEM_XXX options are gone, how do I choose to use system libs rather than compiling the bundled ones ?Ben 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/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/17700diy2 does not compile using intel compiler2019-12-09T13:26:55-05:00Andreas Buykxdiy2 does not compile using intel compilerI'm trying to build VTK (commit 6295ff2235) on linux using our intel compiler and get compiler errors when building diy2.
The errors are related to the expansion of FMT_DEPRECATED, like
```
<path-to-VTK>/ThirdParty/diy2/vtkdiy2/incl...I'm trying to build VTK (commit 6295ff2235) on linux using our intel compiler and get compiler errors when building diy2.
The errors are related to the expansion of FMT_DEPRECATED, like
```
<path-to-VTK>/ThirdParty/diy2/vtkdiy2/include/vtkdiy2/fmt/core.h(478): error: identifier "parse_context" is undefined
using parse_context FMT_DEPRECATED = basic_parse_context<char>;
```
The FMT_DEPRECATED macro is defined as
```
#ifndef FMT_DEPRECATED
# if (FMT_HAS_CPP_ATTRIBUTE(deprecated) && __cplusplus >= 201402L) || \
FMT_MSC_VER >= 1900
# define FMT_DEPRECATED [[deprecated]]
# else
# if defined(__GNUC__) || defined(__clang__)
# define FMT_DEPRECATED __attribute__((deprecated))
# elif FMT_MSC_VER
# define FMT_DEPRECATED __declspec(deprecated)
# else
# define FMT_DEPRECATED /* deprecated */
# endif
# endif
#endif
```
Our compiler version is 19.0.2.187 20190117 which has __cplusplus >= 201402L and supports the [[deprecated]] attribute, but it does not have __has_cpp_attribute (which is a C++20 feature). The FMT_DEPRECATED macro however expands to __attribute__((deprecated)) which causes compiler errors.
I fixed my build by using
```
#ifndef FMT_DEPRECATED
# if (FMT_HAS_CPP_ATTRIBUTE(deprecated) && __cplusplus >= 201402L) || \
FMT_MSC_VER >= 1900 || \
defined(__ICC)
# define FMT_DEPRECATED [[deprecated]]
# else
# if defined(__GNUC__) || defined(__clang__)
# define FMT_DEPRECATED __attribute__((deprecated))
# elif FMT_MSC_VER
# define FMT_DEPRECATED __declspec(deprecated)
# else
# define FMT_DEPRECATED /* deprecated */
# endif
# endif
#endif
```
but this may not work properly I suppose for older intel compilers.
@caitlin.ross Could you please have a look at this? Thanks!9.0https://gitlab.kitware.com/vtk/vtk/-/issues/17725Build error in VTK-based project: “include called with wrong number of argume...2019-11-12T20:12:55-05:00Andras LassoBuild error in VTK-based project: “include called with wrong number of arguments. include() only takes one file.”Build fails when a VTK-based library is configured with VTK-8.90. It worked well with VTK-8.2.
The error message is:
include called with wrong number of arguments. include() only takes one file.
After some digging and internet search ...Build fails when a VTK-based library is configured with VTK-8.90. It worked well with VTK-8.2.
The error message is:
include called with wrong number of arguments. include() only takes one file.
After some digging and internet search it turned out that it caused trouble at a number of other projects, too (VTK examples, PCL, etc).
The solution is to delete include(${VTK_USE_FILE}), which was necessary for building with older VTK versions.
To make transition of projects to VTK-8.9 easier and avoid unnecessary developer frustration, please create a dummy VTK_USE_FILE that prints a meaningful warning message (or prints an error message and aborts the build). This mechanism only needs to kept until most projects make their transition (can be removed in a couple of years).9.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 Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/17733Paraview 5.7 fails to build with openmpi on Fedora Rawhide2022-05-19T18:16:09-04:00Orion PoplawskiParaview 5.7 fails to build with openmpi on Fedora RawhideTrying to update the Fedora paraview package to 5.7. Getting the following:
```
[ 97%] Linking CXX executable ../bin/pvserver
cd /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/CommandLineExecutables && /usr/bin/cma...Trying to update the Fedora paraview package to 5.7. Getting the following:
```
[ 97%] Linking CXX executable ../bin/pvserver
cd /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/CommandLineExecutables && /usr/bin/cmake -E cmake_link_script CMakeFiles/pvserver.dir/link.txt --verbose=1
/usr/bin/c++ -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=zEC12 -mtune=z13 -fasynchronous-unwind-tables -fstack-clash-protection -O2 -g -DNDEBUG -Wl,-lc -Wl,-lc -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld CMakeFiles/pvserver.dir/pvserver.cxx.o -o ../bin/pvserver -Wl,-rpath,"\$ORIGIN/../lib64:/usr/lib64/openmpi/lib:" ../lib64/libvtkPVServerManagerApplication-pv5.7.so.5.7 ../lib64/libvtkUtilitiesPythonInitializer-pv5.7.so.5.7 ../lib64/libvtkPVServerManagerCore-pv5.7.so.5.7 ../lib64/libvtkPVServerImplementationCore-pv5.7.so.5.7 ../lib64/libvtkPVClientServerCoreCore-pv5.7.so.5.7 ../lib64/libvtkPVVTKExtensionsCore-pv5.7.so.5.7 ../lib64/libvtkPVCore-pv5.7.so.5.7 ../lib64/libvtkClientServer-pv5.7.so.5.7 ../lib64/libvtkPythonInterpreter-pv5.7.so.5.7 ../lib64/libvtkIOXMLParser-pv5.7.so.5.7 ../lib64/libvtkIOImage-pv5.7.so.5.7 ../lib64/libvtkPVVTKExtensionsSIL-pv5.7.so.5.7 ../lib64/libvtkFiltersParallel-pv5.7.so.5.7 ../lib64/libvtkFiltersExtraction-pv5.7.so.5.7 ../lib64/libvtkFiltersModeling-pv5.7.so.5.7 ../lib64/libvtkFiltersSources-pv5.7.so.5.7 ../lib64/libvtkFiltersGeneral-pv5.7.so.5.7 ../lib64/libvtkFiltersGeometry-pv5.7.so.5.7 ../lib64/libvtkFiltersCore-pv5.7.so.5.7 ../lib64/libvtkParallelCore-pv5.7.so.5.7 ../lib64/libvtkIOLegacy-pv5.7.so.5.7 ../lib64/libvtkIOCore-pv5.7.so.5.7 /usr/lib64/libprotobuf.so /usr/lib64/libjsoncpp.so ../lib64/libvtkCommonExecutionModel-pv5.7.so.5.7 ../lib64/libvtkCommonDataModel-pv5.7.so.5.7 ../lib64/libvtkCommonSystem-pv5.7.so.5.7 ../lib64/libvtkCommonMisc-pv5.7.so.5.7 ../lib64/libvtkCommonTransforms-pv5.7.so.5.7 ../lib64/libvtkCommonMath-pv5.7.so.5.7 ../lib64/libvtkCommonCore-pv5.7.so.5.7 -lpthread /usr/lib64/libpython3.8.so ../lib64/libvtksys-pv5.7.so.5.7 -ldl -Wl,-rpath-link,/builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/lib64:/usr/lib64/openmpi/lib
make[2]: Leaving directory '/builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi'
/usr/bin/ld: /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/lib64/libvtkIOXdmf2-pv5.7.so.1: undefined reference to `ompi_mpi_cxx_op_intercept'
/usr/bin/ld: /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/lib64/libvtkIOXdmf2-pv5.7.so.1: undefined reference to `MPI::Win::Free()'
/usr/bin/ld: /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/lib64/libvtkIOXdmf2-pv5.7.so.1: undefined reference to `MPI::Datatype::Free()'
/usr/bin/ld: /builddir/build/BUILD/ParaView-v5.7.0/s390x-redhat-linux-gnu-openmpi/lib64/libvtkIOXdmf2-pv5.7.so.1: undefined reference to `MPI::Comm::Comm()'
collect2: error: ld returned 1 exit status
make[2]: *** [CommandLineExecutables/CMakeFiles/pvserver.dir/build.make:120: bin/pvserver] Error 1
```
Full log: https://kojipkgs.fedoraproject.org//work/tasks/1379/39091379/build.log. See this on all arches.9.0Ben 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/17756Update vendored expat2020-07-08T15:49:28-04:00Ben BoeckelUpdate vendored expatExpat 2.2.9 is out, but we import 2.2.6. There was some issue with updating in !6340 that needs looked at.Expat 2.2.9 is out, but we import 2.2.6. There was some issue with updating in !6340 that needs looked at.Cory Quammencory.quammen@kitware.comCory Quammencory.quammen@kitware.comhttps://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/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/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/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/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/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/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/17852Fix example PATH handling2021-04-14T16:11:53-04:00Ben BoeckelFix example PATH handlingIn the Examples code, `PATH` is set as a test property at configure time. Instead, the `TEST_INCLUDE_FILES` directory property should be used to augment the environment at test time. It looks like this is available in 3.12.
Cc: @tjcoron...In the Examples code, `PATH` is set as a test property at configure time. Instead, the `TEST_INCLUDE_FILES` directory property should be used to augment the environment at test time. It looks like this is available in 3.12.
Cc: @tjcorona @brad.kingBen BoeckelBen Boeckelhttps://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/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/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/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/17994VTK_CUSTOM_LIBRARY_SUFFIX is not set to empty string on Linux2020-09-02T07:26:50-04:00JensgwVTK_CUSTOM_LIBRARY_SUFFIX is not set to empty string on LinuxWhen compiling VTK-9.0.1 (on debian/10) VTK_CUSTOM_LIBRARY_SUFFIX ist not set to an empty string when VTK_VERSIONED_INSTALL is false. This leads to the generation of libraries with version numbers. But that was not the intention with tur...When compiling VTK-9.0.1 (on debian/10) VTK_CUSTOM_LIBRARY_SUFFIX ist not set to an empty string when VTK_VERSIONED_INSTALL is false. This leads to the generation of libraries with version numbers. But that was not the intention with turning the versioned install off.https://gitlab.kitware.com/vtk/vtk/-/issues/18033Provide or replace `FT_CALLBACK_DEF`2021-10-21T15:48:35-04:00ccornProvide or replace `FT_CALLBACK_DEF`freetype as of v2.10.3 [no longer exports `FT_CALLBACK_DEF`][1].
This breaks builds of VTK-8.2.0 when using the system's freetype:
/build/vtk/src/VTK-8.2.0/Rendering/FreeType/vtkFreeTypeTools.cxx:391:1: error: expected constructor, ...freetype as of v2.10.3 [no longer exports `FT_CALLBACK_DEF`][1].
This breaks builds of VTK-8.2.0 when using the system's freetype:
/build/vtk/src/VTK-8.2.0/Rendering/FreeType/vtkFreeTypeTools.cxx:391:1: error: expected constructor, destructor, or type conversion before ‘vtkFreeTypeToolsFaceRequester’
391 | vtkFreeTypeToolsFaceRequester(FTC_FaceID face_id,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/build/vtk/src/VTK-8.2.0/Rendering/FreeType/vtkFreeTypeTools.cxx: In member function ‘virtual FT_Error vtkFreeTypeTools::CreateFTCManager()’:
/build/vtk/src/VTK-8.2.0/Rendering/FreeType/vtkFreeTypeTools.cxx:1252:26: error: ‘vtkFreeTypeToolsFaceRequester’ was not declared in this scope; did you mean ‘vtkFreeTypeToolsCleanupCounter’?
Source files using `FT_CALLBACK_DEF` are:
- `Rendering/FreeType/vtkFreeTypeTools.cxx`
- `Rendering/FreeTypeFontConfig/vtkFontConfigFreeTypeTools.cxx`
The attached patch files (to be applied with `-p1`) each work around this error.
Each patch file is sufficient; you may want to think about their pros and contras.
1. Provide the (unchanged) definition of `FT_CALLBACK_DEF`,
unless already defined, in `ThirdParty/freetype/vtk_freetype.h.in`.
This eliminates the need to change the usage.
2. Explicitly eliminate the reference to `FT_CALLBACK_DEF` at the points
of usage. This basically means using `extern "C"` explicitly and seems
to match the intent of the freetype developers more closely, but the
freetype definition still notes the following caveat:
/* Some 16bit compilers have to redefine these macros to insert */
/* the infamous `_cdecl` or `__fastcall` declarations. */
If that flexibility is important to you, better stick with (1).
Note that `vtkFontConfigFreeTypeTools.cxx` wraps an anonymous namespace
around the `FT_CALLBACK_DEF`. The second patch removes that anonymous
namespace because its effect is undone by the `extern "C"` anyway.
[1]: https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=bb66c8d8cf1eb86309273d7c53c44522d35941d4
[vtk-freetype-2.10.3-provide-FT_CALLBACK_DEF.patch](/uploads/a5354808a4167e6fa9208c8c03ffd105/vtk-freetype-2.10.3-provide-FT_CALLBACK_DEF.patch)
[vtk-freetype-2.10.3-replace-FT_CALLBACK_DEF.patch](/uploads/c6fa799a1a028b8f8a728a40d26d3fec/vtk-freetype-2.10.3-replace-FT_CALLBACK_DEF.patch)https://gitlab.kitware.com/vtk/vtk/-/issues/18037High memory usage TUs2020-12-09T21:34:28-05:00Ben BoeckelHigh memory usage TUsI've been seeing OOM situations arise more and more recently of late with VTK-m. This issue aims to document the high-usage memory TUs. Note that I do not have CUDA enabled, and memory usage tends to be higher with its toolchain.
Config...I've been seeing OOM situations arise more and more recently of late with VTK-m. This issue aims to document the high-usage memory TUs. Note that I do not have CUDA enabled, and memory usage tends to be higher with its toolchain.
Configuration: RelWithDebInfo, no CUDA, GCC 10.2.1. Running the build with `systemd-run --user -p MemoryMax=$memory --setenv=CCACHE_DISABLE=1 --same-dir --pty ninja -j1 $target`
TUs that fail with `memory=4G`:
- [x] `Accelerators/Vtkm/Filters/CMakeFiles/AcceleratorsVTKmFilters.dir/vtkmClip.cxx.o`
- [x] `Accelerators/Vtkm/Filters/CMakeFiles/AcceleratorsVTKmFilters.dir/vtkmClipWithField.cxx.o`
- [x] `Accelerators/Vtkm/Filters/CMakeFiles/AcceleratorsVTKmFilters.dir/vtkmGradient.cxx.o`
Will update as things progress.
# EDITED (Nov 23rd 2020)
## Progress
- [x] [VTKm optimizations] in vtkm repo (https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7390)
- [x] [vtkmClip optimizations] in vtk repo (https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7397)
After the above tasks we were able to reduce the compilation memory usage in the following manner:
Version | Size sum of object files | Minimum memory to compile
--------|--------------------------|--------------------------
Before | 129M | 5GiB
1st MR | 74M | 4GiB
2nd MR | 107MiB | 3GiB
See: vtk-m#578
Cc: @vbolea @robertmaynardVicente Boleavicente.bolea@kitware.comVicente Boleavicente.bolea@kitware.comhttps://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/18050vtkexodusII fails to build gcc 4.9.4 / gcc 4.8.52020-11-11T09:27:11-05:00chart3388vtkexodusII fails to build gcc 4.9.4 / gcc 4.8.5ParaView latest master fails to build with GCC-4.9.4 and GCC-4.8.5. This was using the superbuild with the following options:
```
cmake -G Ninja \
-DCMAKE_BUILD_TYPE=Release \
-DENABLE_python=ON \
-DENABLE_python3=ON \
-DENA...ParaView latest master fails to build with GCC-4.9.4 and GCC-4.8.5. This was using the superbuild with the following options:
```
cmake -G Ninja \
-DCMAKE_BUILD_TYPE=Release \
-DENABLE_python=ON \
-DENABLE_python3=ON \
-DENABLE_ffmpeg=ON \
-DENABLE_qt5=ON \
-Dqt5_SOURCE_SELECTION=5.12 \
-DENABLE_ospray=ON \
-Dparaview_SOURCE_SELECTION=git \
../paraview-superbuild
```
```
[22/11929] Building C object VTK/ThirdParty/exodu...CMakeFiles/exodusII.dir/src/ex_get_assemblies.c.
FAILED: VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_assemblies.c.o
/opt/jenkins/jenkins-tools/gcc-4.9.4/bin/gcc -DH5_BUILT_AS_DYNAMIC_LIB -DexoIIc_EXPORTS -DexodusII_EXPORTS -IVTK/ThirdParty/exodusII/vtkexodusII -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/include -IVTK/ThirdParty/exodusII/vtkexodusII/include -IVTK/ThirdParty/hdf5/vtkhdf5 -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5 -IVTK/ThirdParty/hdf5/vtkhdf5/src -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5/src -IVTK/ThirdParty/hdf5/vtkhdf5/hl/src -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5/hl/src -IVTK/ThirdParty/netcdf/vtknetcdf -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/netcdf/vtknetcdf -isystem VTK/ThirdParty/exodusII -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII -isystem VTK/ThirdParty/hdf5 -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5 -isystem VTK/ThirdParty/netcdf -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/netcdf -fPIC -O3 -DNDEBUG -fPIC -MD -MT VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_assemblies.c.o -MF VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_assemblies.c.o.d -o VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_assemblies.c.o -c /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_assemblies.c
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_assemblies.c: In function ‘vtkexodusII_ex_get_assemblies’:
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_assemblies.c:62:5: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (int i = 0; i < num_assembly; i++) {
^
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_assemblies.c:62:5: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_assemblies.c:70:5: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (int i = 0; i < num_assembly; i++) {
^
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_assemblies.c:76:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (int i = 0; i < num_assembly; i++) {
^
[23/11929] Building C object VTK/ThirdParty/exodu...odusII/CMakeFiles/exodusII.dir/src/ex_get_ids.c.
FAILED: VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_ids.c.o
/opt/jenkins/jenkins-tools/gcc-4.9.4/bin/gcc -DH5_BUILT_AS_DYNAMIC_LIB -DexoIIc_EXPORTS -DexodusII_EXPORTS -IVTK/ThirdParty/exodusII/vtkexodusII -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/include -IVTK/ThirdParty/exodusII/vtkexodusII/include -IVTK/ThirdParty/hdf5/vtkhdf5 -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5 -IVTK/ThirdParty/hdf5/vtkhdf5/src -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5/src -IVTK/ThirdParty/hdf5/vtkhdf5/hl/src -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5/hl/src -IVTK/ThirdParty/netcdf/vtknetcdf -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/netcdf/vtknetcdf -isystem VTK/ThirdParty/exodusII -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII -isystem VTK/ThirdParty/hdf5 -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5 -isystem VTK/ThirdParty/netcdf -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/netcdf -fPIC -O3 -DNDEBUG -fPIC -MD -MT VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_ids.c.o -MF VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_ids.c.o.d -o VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_ids.c.o -c /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_ids.c
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_ids.c: In function ‘ex_get_nonstandard_ids’:
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_ids.c:87:5: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (int varid = 0; varid < nvars; varid++) {
^
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_ids.c:87:5: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
[24/11929] Building C object VTK/ThirdParty/exodu...I/CMakeFiles/exodusII.dir/src/ex_get_init_ext.c.
FAILED: VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_init_ext.c.o
/opt/jenkins/jenkins-tools/gcc-4.9.4/bin/gcc -DH5_BUILT_AS_DYNAMIC_LIB -DexoIIc_EXPORTS -DexodusII_EXPORTS -IVTK/ThirdParty/exodusII/vtkexodusII -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/include -IVTK/ThirdParty/exodusII/vtkexodusII/include -IVTK/ThirdParty/hdf5/vtkhdf5 -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5 -IVTK/ThirdParty/hdf5/vtkhdf5/src -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5/src -IVTK/ThirdParty/hdf5/vtkhdf5/hl/src -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5/hl/src -IVTK/ThirdParty/netcdf/vtknetcdf -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/netcdf/vtknetcdf -isystem VTK/ThirdParty/exodusII -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII -isystem VTK/ThirdParty/hdf5 -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5 -isystem VTK/ThirdParty/netcdf -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/netcdf -fPIC -O3 -DNDEBUG -fPIC -MD -MT VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_init_ext.c.o -MF VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_init_ext.c.o.d -o VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_init_ext.c.o -c /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_init_ext.c
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_init_ext.c: In function ‘ex__get_entity_count’:
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_init_ext.c:58:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (int dimid = 0; dimid < ndims; dimid++) {
^
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_init_ext.c:58:3: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
[25/11929] Building C object VTK/ThirdParty/exodu...dusII.dir/src/ex__put_homogenous_block_params.c.
FAILED: VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex__put_homogenous_block_params.c.o
/opt/jenkins/jenkins-tools/gcc-4.9.4/bin/gcc -DH5_BUILT_AS_DYNAMIC_LIB -DexoIIc_EXPORTS -DexodusII_EXPORTS -IVTK/ThirdParty/exodusII/vtkexodusII -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/include -IVTK/ThirdParty/exodusII/vtkexodusII/include -IVTK/ThirdParty/hdf5/vtkhdf5 -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5 -IVTK/ThirdParty/hdf5/vtkhdf5/src -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5/src -IVTK/ThirdParty/hdf5/vtkhdf5/hl/src -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5/hl/src -IVTK/ThirdParty/netcdf/vtknetcdf -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/netcdf/vtknetcdf -isystem VTK/ThirdParty/exodusII -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII -isystem VTK/ThirdParty/hdf5 -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5 -isystem VTK/ThirdParty/netcdf -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/netcdf -fPIC -O3 -DNDEBUG -fPIC -MD -MT VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex__put_homogenous_block_params.c.o -MF VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex__put_homogenous_block_params.c.o.d -o VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex__put_homogenous_block_params.c.o -c /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex__put_homogenous_block_params.c
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex__put_homogenous_block_params.c: In function ‘vtkexodusII_ex__put_homogenous_block_params’:
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex__put_homogenous_block_params.c:89:5: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (size_t i = 0; i < block_count; i++) {
^
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex__put_homogenous_block_params.c:89:5: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex__put_homogenous_block_params.c:122:5: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (size_t i = 0; i < block_count; i++) {
^
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex__put_homogenous_block_params.c:160:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (size_t i = 0; i < block_count; i++) {
^
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex__put_homogenous_block_params.c:393:15: error: redefinition of ‘i’
for (size_t i = 0; i < block_count; i++) {
^
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex__put_homogenous_block_params.c:160:15: note: previous definition of ‘i’ was here
for (size_t i = 0; i < block_count; i++) {
^
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex__put_homogenous_block_params.c:393:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (size_t i = 0; i < block_count; i++) {
^
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex__put_homogenous_block_params.c:416:7: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (size_t j = 0; j < blocks[i].num_attribute; j++) {
^
[26/11929] Building C object VTK/ThirdParty/exodu...usII/CMakeFiles/exodusII.dir/src/ex_get_blobs.c.
FAILED: VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_blobs.c.o
/opt/jenkins/jenkins-tools/gcc-4.9.4/bin/gcc -DH5_BUILT_AS_DYNAMIC_LIB -DexoIIc_EXPORTS -DexodusII_EXPORTS -IVTK/ThirdParty/exodusII/vtkexodusII -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/include -IVTK/ThirdParty/exodusII/vtkexodusII/include -IVTK/ThirdParty/hdf5/vtkhdf5 -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5 -IVTK/ThirdParty/hdf5/vtkhdf5/src -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5/src -IVTK/ThirdParty/hdf5/vtkhdf5/hl/src -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5/hl/src -IVTK/ThirdParty/netcdf/vtknetcdf -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/netcdf/vtknetcdf -isystem VTK/ThirdParty/exodusII -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII -isystem VTK/ThirdParty/hdf5 -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5 -isystem VTK/ThirdParty/netcdf -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/netcdf -fPIC -O3 -DNDEBUG -fPIC -MD -MT VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_blobs.c.o -MF VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_blobs.c.o.d -o VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_blobs.c.o -c /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_blobs.c
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_blobs.c: In function ‘vtkexodusII_ex_get_blobs’:
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_blobs.c:59:5: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (int i = 0; i < num_blob; i++) {
^
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_blobs.c:59:5: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_blobs.c:67:5: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (int i = 0; i < num_blob; i++) {
^
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_blobs.c:73:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (int i = 0; i < num_blob; i++) {
^
[27/11929] Building C object VTK/ThirdParty/exodu.../CMakeFiles/exodusII.dir/src/ex_get_attribute.c.
FAILED: VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_attribute.c.o
/opt/jenkins/jenkins-tools/gcc-4.9.4/bin/gcc -DH5_BUILT_AS_DYNAMIC_LIB -DexoIIc_EXPORTS -DexodusII_EXPORTS -IVTK/ThirdParty/exodusII/vtkexodusII -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/include -IVTK/ThirdParty/exodusII/vtkexodusII/include -IVTK/ThirdParty/hdf5/vtkhdf5 -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5 -IVTK/ThirdParty/hdf5/vtkhdf5/src -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5/src -IVTK/ThirdParty/hdf5/vtkhdf5/hl/src -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5/vtkhdf5/hl/src -IVTK/ThirdParty/netcdf/vtknetcdf -I/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/netcdf/vtknetcdf -isystem VTK/ThirdParty/exodusII -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII -isystem VTK/ThirdParty/hdf5 -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/hdf5 -isystem VTK/ThirdParty/netcdf -isystem /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/netcdf -fPIC -O3 -DNDEBUG -fPIC -MD -MT VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_attribute.c.o -MF VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_attribute.c.o.d -o VTK/ThirdParty/exodusII/vtkexodusII/CMakeFiles/exodusII.dir/src/ex_get_attribute.c.o -c /opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_attribute.c
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_attribute.c: In function ‘vtkexodusII_ex_get_attribute_count’:
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_attribute.c:189:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (int i = 0; i < count; i++) {
^
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_attribute.c:189:3: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_attribute.c: In function ‘vtkexodusII_ex_get_attribute_param’:
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_attribute.c:238:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (int i = 0; i < att_count; i++) {
^
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_attribute.c: In function ‘vtkexodusII_ex_get_attributes’:
/opt/jenkins/workspace/GIE_AXION_171570_SLES-paraview-nightly/build1/superbuild/paraview/src/VTK/ThirdParty/exodusII/vtkexodusII/src/ex_get_attribute.c:327:3: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (size_t i = 0; i < attr_count; i++) {
^
[55/11929] Building CXX object CMakeFiles/vtkIOPa...llelXMLPython/vtkXMLPDataObjectWriterPython.cxx.
ninja: build stopped: subcommand failed.
```Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18096macOS deprecation warnings2021-02-03T10:09:51-05:00Ben BoeckelmacOS deprecation warningsVTK is currently using some APIs which are deprecated in the newest macOS releases. Could these be resolved at some point?
```
../VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm:391:22: warning: 'view' is deprecated: first deprecated in m...VTK is currently using some APIs which are deprecated in the newest macOS releases. Could these be resolved at some point?
```
../VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm:391:22: warning: 'view' is deprecated: first deprecated in macOS 10.14 [-Wdeprecated-declarations]
bool ok = [context view] != nil;
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:193:36: note: property 'view' is declared deprecated here
@property (nullable, weak) NSView *view API_DEPRECATED("", macos(10.0,10.14));
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:193:36: note: 'view' has been explicitly marked deprecated here
../VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm:862:15: warning: 'setWantsBestResolutionOpenGLSurface:' is deprecated: first deprecated in macOS 10.14 - Use NSOpenGLView instead. [-Wdeprecated-declarations]
[glView setWantsBestResolutionOpenGLSurface:wantsBest];
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGLView.h:47:16: note: property 'wantsBestResolutionOpenGLSurface' is declared deprecated here
@property BOOL wantsBestResolutionOpenGLSurface API_DEPRECATED("Use NSOpenGLView instead.", macos(10.7,10.14));
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGLView.h:47:16: note: 'setWantsBestResolutionOpenGLSurface:' has been explicitly marked deprecated here
../VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm:882:15: warning: 'setWantsBestResolutionOpenGLSurface:' is deprecated: first deprecated in macOS 10.14 - Use NSOpenGLView instead. [-Wdeprecated-declarations]
[glView setWantsBestResolutionOpenGLSurface:wantsBest];
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGLView.h:47:16: note: property 'wantsBestResolutionOpenGLSurface' is declared deprecated here
@property BOOL wantsBestResolutionOpenGLSurface API_DEPRECATED("Use NSOpenGLView instead.", macos(10.7,10.14));
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGLView.h:47:16: note: 'setWantsBestResolutionOpenGLSurface:' has been explicitly marked deprecated here
../VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm:903:14: warning: 'setView:' is deprecated: first deprecated in macOS 10.14 - Use NSOpenGLView to provide OpenGL content in a Cocoa app. [-Wdeprecated-declarations]
[context setView:view];
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:193:36: note: property 'view' is declared deprecated here
@property (nullable, weak) NSView *view API_DEPRECATED("", macos(10.0,10.14));
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:194:1: note: 'setView:' has been explicitly marked deprecated here
- (void)setView:(nullable NSView *)view API_DEPRECATED("Use NSOpenGLView to provide OpenGL content in a Cocoa app.", macos(10.0,10.14));
^
../VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm:1025:42: warning: 'NSOpenGLCPSwapInterval' is deprecated: first deprecated in macOS 10.14 [-Wdeprecated-declarations]
[context setValues:&one forParameter:NSOpenGLCPSwapInterval];
^~~~~~~~~~~~~~~~~~~~~~
NSOpenGLContextParameterSwapInterval
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:258:39: note: 'NSOpenGLCPSwapInterval' has been explicitly marked deprecated here
static const NSOpenGLContextParameter NSOpenGLCPSwapInterval API_DEPRECATED_WITH_REPLACEMENT("NSOpenGLContextParameterSwapInterval", macos(10.5,10.14)) = NSOpenGLContextParameterSwapInterval;
^
../VTK/Rendering/OpenGL2/vtkCocoaRenderWindow.mm:1061:16: warning: 'setView:' is deprecated: first deprecated in macOS 10.14 - Use NSOpenGLView to provide OpenGL content in a Cocoa app. [-Wdeprecated-declarations]
[context setView:view];
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:193:36: note: property 'view' is declared deprecated here
@property (nullable, weak) NSView *view API_DEPRECATED("", macos(10.0,10.14));
^
/Applications/Xcode-12.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSOpenGL.h:194:1: note: 'setView:' has been explicitly marked deprecated here
- (void)setView:(nullable NSView *)view API_DEPRECATED("Use NSOpenGLView to provide OpenGL content in a Cocoa app.", macos(10.0,10.14));
^
6 warnings generated.
```
Cc: @seanm @cory.quammenSean McBrideSean McBridehttps://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/18108CUDA configuration with Kepler and >=cuda-11 fails in vtkm2021-02-03T17:06:59-05:00BerndCUDA configuration with Kepler and >=cuda-11 fails in vtkmHello,
when configuring the VTK project, version 9.0.1, with a Kepler CUDA compute arch using >=cuda-11 cmake isn't able to finish this step properly. In `ThirdParty/vtkm/vtkvtkm/vtk-m/CMake/VTKmDeviceAdapters.cmake` both, compute_30 an...Hello,
when configuring the VTK project, version 9.0.1, with a Kepler CUDA compute arch using >=cuda-11 cmake isn't able to finish this step properly. In `ThirdParty/vtkm/vtkvtkm/vtk-m/CMake/VTKmDeviceAdapters.cmake` both, compute_30 and compute_35 arches are set and passed to the `--generate-code` flag for nvcc.
However, starting with CUDA-11, the compute_30 arches are no longer supported, so the configuration fails. For Gentoo, I found the attached patch to solve this issue (see also https://github.com/gentoo/gentoo/blob/b4515ef3e96a9e3cdfe5723141fe0a0ca5fa4d56/sci-libs/vtk/files/vtk-9.0.1-0001-fix-kepler-compute_arch-if-CUDA-toolkit-11-is-used.patch).
I haven't tested with the master branch, but the code hasn't changed, so I assume, the issue will be present for current HEAD too.
[vtk-9.0.1-0001-fix-kepler-compute_arch-if-CUDA-toolkit-11-is-used.patch](/uploads/bd1c4d3ef1aecceec06bb630f865b36d/vtk-9.0.1-0001-fix-kepler-compute_arch-if-CUDA-toolkit-11-is-used.patch)https://gitlab.kitware.com/vtk/vtk/-/issues/18112FindTBB: support tbb-config.cmake2021-02-25T12:28:31-05:00Ben BoeckelFindTBB: support tbb-config.cmakeFindTBB currently always does searching on its own. Support for the new `tbb-config.cmake` (`find_package(TBB CONFIG)`) needs to be added when available, only falling back when it is not available.
Cc: @robertmaynard @jcfrFindTBB currently always does searching on its own. Support for the new `tbb-config.cmake` (`find_package(TBB CONFIG)`) needs to be added when available, only falling back when it is not available.
Cc: @robertmaynard @jcfrBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18130Fails to build with PROJ 8.0.0 (proj_api.h removed)2021-03-13T18:35:44-05:00Bas CouwenbergFails to build with PROJ 8.0.0 (proj_api.h removed)Follow up to #17554.
VTK fails to build with PROJ 8.0.0 which has removed `proj_api.h`.
While suppport for `proj.h` has been added, `proj_api.h` is also still used:
```c
#if VTK_MODULE_USE_EXTERNAL_vtklibproj
# if VTK_LibPROJ_MAJOR_VER...Follow up to #17554.
VTK fails to build with PROJ 8.0.0 which has removed `proj_api.h`.
While suppport for `proj.h` has been added, `proj_api.h` is also still used:
```c
#if VTK_MODULE_USE_EXTERNAL_vtklibproj
# if VTK_LibPROJ_MAJOR_VERSION >= 5
# include <proj.h>
# endif
# if VTK_LibPROJ_MAJOR_VERSION < 6
# include <projects.h>
# endif
# if VTK_LibPROJ_MAJOR_VERSION >= 6
# define ACCEPT_USE_OF_DEPRECATED_PROJ_API_H 1
# endif
# include <proj_api.h>
# include <geodesic.h>
#else
# include <vtklibproj/src/projects.h>
# include <vtklibproj/src/proj_api.h>
# include <vtklibproj/src/geodesic.h>
#endif
```
Restricting this to only use `proj.h` shows that the code still relies on `proj_api.h` features and has not been properly ported to the PROJ 6 API:
```cmake
/build/vtk9-9.0.1+dfsg1/Geovis/Core/vtkGeoProjection.cxx: In destructor 'virtual vtkGeoProjection::~vtkGeoProjection()':
/build/vtk9-9.0.1+dfsg1/Geovis/Core/vtkGeoProjection.cxx:124:5: error: 'pj_free' was not declared in this scope; did you mean 'free'?
124 | pj_free(this->Projection);
| ^~~~~~~
| free
/build/vtk9-9.0.1+dfsg1/Geovis/Core/vtkGeoProjection.cxx: In member function 'virtual int vtkGeoProjection::UpdateProjection()':
/build/vtk9-9.0.1+dfsg1/Geovis/Core/vtkGeoProjection.cxx:188:5: error: 'pj_free' was not declared in this scope; did you mean 'free'?
188 | pj_free(this->Projection);
| ^~~~~~~
| free
/build/vtk9-9.0.1+dfsg1/Geovis/Core/vtkGeoProjection.cxx:194:24: error: 'pj_init_plus' was not declared in this scope
194 | this->Projection = pj_init_plus(this->PROJ4String);
| ^~~~~~~~~~~~
/build/vtk9-9.0.1+dfsg1/Geovis/Core/vtkGeoProjection.cxx:234:24: error: 'pj_init' was not declared in this scope; did you mean 'u_int'?
234 | this->Projection = pj_init(argSize, const_cast<char**>(pjArgs));
| ^~~~~~~
| u_int
make[4]: *** [Geovis/Core/CMakeFiles/GeovisCore.dir/build.make:111: Geovis/Core/CMakeFiles/GeovisCore.dir/vtkGeoProjection.cxx.o] Error 1
```
The following patch was used to test the build with PROJ 8.0.0:
```patch
--- a/ThirdParty/libproj/vtk_libproj.h.in
+++ b/ThirdParty/libproj/vtk_libproj.h.in
@@ -32,10 +32,10 @@
# if VTK_LibPROJ_MAJOR_VERSION < 6
# include <projects.h>
# endif
-# if VTK_LibPROJ_MAJOR_VERSION >= 6
+# if VTK_LibPROJ_MAJOR_VERSION >= 6 && VTK_LibPROJ_MAJOR_VERSION < 8
# define ACCEPT_USE_OF_DEPRECATED_PROJ_API_H 1
+# include <proj_api.h>
# endif
-# include <proj_api.h>
# include <geodesic.h>
#else
# include <vtklibproj/src/projects.h>
```https://gitlab.kitware.com/vtk/vtk/-/issues/18144VTK::FiltersCorePython-QuadricDecimation2 test exclusion2021-09-02T21:03:13-04:00Ben BoeckelVTK::FiltersCorePython-QuadricDecimation2 test exclusionThe `VTK::FiltersCorePython-QuadricDecimation2` test is currently excluded on Windows CI. See the failure [here](https://open.cdash.org/test/360245245). The test passed on the CI Windows branch based off of 64c97df4874be90b63e5fad4350928...The `VTK::FiltersCorePython-QuadricDecimation2` test is currently excluded on Windows CI. See the failure [here](https://open.cdash.org/test/360245245). The test passed on the CI Windows branch based off of 64c97df4874be90b63e5fad43509284de6d97026, so presumably something in that range is to blame.
Cc: @cory.quammenBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18208Keep track of why modules are provided/requested/rejected/etc.2021-05-12T08:19:29-04:00Ben BoeckelKeep track of why modules are provided/requested/rejected/etc.The module system should track why modules are enabled, provided, rejected, etc. for use in error messages. Currently this information is visible through debug flags and logging, but the error messages are a bit lost as to the actual rea...The module system should track why modules are enabled, provided, rejected, etc. for use in error messages. Currently this information is visible through debug flags and logging, but the error messages are a bit lost as to the actual reasons behind things.
Cc: @cory.quammenBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18226gitlab-ci: harmonize with other Kitware project setups2021-05-28T15:25:57-04:00Ben Boeckelgitlab-ci: harmonize with other Kitware project setupsThe CI setup in VTK-m is slightly different from other Kitware projects. Of particular note, the machine setup is completely different. It is getting more and more difficult to maintain the machines since they have all kinds of exception...The CI setup in VTK-m is slightly different from other Kitware projects. Of particular note, the machine setup is completely different. It is getting more and more difficult to maintain the machines since they have all kinds of exceptions on them. We (@brad.king and I) would like to reinstall these machines and sync them up with the rest of our machine setups:
- [ ] abeth
- [ ] renar
- [ ] umbra
In addition, there are machines still running buildbot jobs:
- [ ] dragnipur
- [ ] osheim
that would be also end up being reinstalled (though their other builds would need converted into CI jobs, mainly DIY).
Also of note is that macOS and Windows machines *only* contain:
- Git installation (with `git-lfs`)
- macOS only
- Xcode (macOS only)
- Windows only
- Visual Studio (and relevant toolchains)
- CUDA/NVIDIA drivers
- `sccache` binaries
- MSMPI (if needed for a project)
Everything else (including CMake and `ninja`) should be downloaded during the CI job so as to avoid having to juggle lots of software installation across many eligible machines.
Full task list:
- Use existing CI machines for existing CI jobs
- [ ] requires using [the same tagging strategy](https://gitlab.kitware.com/utils/ci-base-images/-/blob/master/doc/tags.md) used on the rest of the fleet
- Linux
- [ ] add NVIDIA hardware tags to existing machines
- [ ] disable VTK-m Linux runners to ensure jobs work on the temporary machines
- [ ] reinstall VTK-m Linux CI machines
- Add temporary runners for macOS and Windows to existing machines
- macOS
- [ ] `tunja`
- Windows
- [ ] `bop`
- [ ] `pol`
- Migrate Buildbot configurations to CI jobs
- [ ] `dragnipur-release` (macOS)
- [ ] `dragnipur-debug` (macOS)
- [ ] `osheim-release` (Windows)
- [ ] `osheim-debug` (Windows)
Cc: @vboleahttps://gitlab.kitware.com/vtk/vtk/-/issues/18265Fails to build against HDF5 1.12.12021-08-26T07:57:47-04:00Bruno PaganiFails to build against HDF5 1.12.1There is a build failure when building against HDF5 1.12.1 that comes from https://gitlab.kitware.com/vtk/vtk/-/blob/master/ThirdParty/xdmf3/vtkxdmf3/core/XdmfHDF5Controller.hpp.
I’ve opened an issue at https://gitlab.kitware.com/xdmf/x...There is a build failure when building against HDF5 1.12.1 that comes from https://gitlab.kitware.com/vtk/vtk/-/blob/master/ThirdParty/xdmf3/vtkxdmf3/core/XdmfHDF5Controller.hpp.
I’ve opened an issue at https://gitlab.kitware.com/xdmf/xdmf/-/issues/28, hopefully this is the correct way for this kind of issues.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18291Newest FindMPI incompatible with cmake < 3.182021-08-30T16:46:51-04:00David GobbiNewest FindMPI incompatible with cmake < 3.18The FindMPI patch in !8322 causes config errors with cmake 3.16 when `VTK_USE_MPI` is enabled:
```
CMake error at CMakeFiles/CMakeTmp/CMakeLists.txt:20 (target_link_libraries):
Error evaluating generator expression:
$<HOST_LINK:SHE...The FindMPI patch in !8322 causes config errors with cmake 3.16 when `VTK_USE_MPI` is enabled:
```
CMake error at CMakeFiles/CMakeTmp/CMakeLists.txt:20 (target_link_libraries):
Error evaluating generator expression:
$<HOST_LINK:SHELL:-pthread>
Expression did not evaluate to a known generator expression
CMake Error at CMake/patches/3.22/FindMPI.cmake:1266 (try_compile):
Failed to generate test project build system.
Call Stack (most recent call first):
CMake/patches/3.22/FindMPI.cmake:1317 (_MPI_try_staged_settings)
CMake/patches/3.22/FindMPI.cmake:1607 (_MPI_check_lang_works)
CMake/vtkModule.cmake:4360 (find_package)
CMake/vtkModule.cmake:4960 (vtk_module_find_package)
Utilities/MPI/CMakeLists.txt:1 (vtk_module_third_party_external)
```
Currently, VTK is targeting compatibility with cmake 3.12 and above.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18296compilation fails with stable fmt2021-09-13T02:41:51-04:00Julien Schuellercompilation fails with stable fmtwith gcc compilation fails with external fmt 8.0.1 (VTK_MODULE_USE_EXTERNAL_VTK_fmt=OFF)
```
vtkPVStringFormatter.h:153:9: error: use of deleted function ‘fmt::v8::dynamic_format_arg_store<fmt::v8::basic_format_context<fmt::v8::appender,...with gcc compilation fails with external fmt 8.0.1 (VTK_MODULE_USE_EXTERNAL_VTK_fmt=OFF)
```
vtkPVStringFormatter.h:153:9: error: use of deleted function ‘fmt::v8::dynamic_format_arg_store<fmt::v8::basic_format_context<fmt::v8::appender, char> >::dynamic_format_arg_store(const fmt::v8::dynamic_format_arg_store<fmt::v8::basic_format_context<fmt::v8::appender, char> >&)’
153 | : Args(args.Args)
| ^~~~~~~~~~~~~~~
```
is this a known issue ? is this an upstream issue ? seems the bundled one is some git version
cc @cory.quammen as you updated it last