VTK issueshttps://gitlab.kitware.com/vtk/vtk/-/issues2022-07-13T07:09:06-04:00https://gitlab.kitware.com/vtk/vtk/-/issues/18593CMake CheckCompilerFlag not found error with CMake version lower than 3.192022-07-13T07:09:06-04:00Stéphane ALBERTCMake CheckCompilerFlag not found error with CMake version lower than 3.19Building on Debian 10 with _GCC 8.3_ and _CMake 3.13.4_ causes the following _CMake_ configure error:
```
CMake Error at CMake/vtkCompilerWarningFlags.cmake:5 (include):
include could not find load file:
CheckCompilerFlag
Call Sta...Building on Debian 10 with _GCC 8.3_ and _CMake 3.13.4_ causes the following _CMake_ configure error:
```
CMake Error at CMake/vtkCompilerWarningFlags.cmake:5 (include):
include could not find load file:
CheckCompilerFlag
Call Stack (most recent call first):
CMakeLists.txt:54 (include)
```
In deed, [`CheckCompilerFlag`](https://cmake.org/cmake/help/latest/module/CheckCompilerFlag.html) is available since _CMake 3.19_, but the `cmake_minimum_required()` is limited to the `3.12...3.16` range in the main `CMakeLists.txt`.
I followed the contribution and development guidelines and pushed a fix on the [`CMake-3.19-CheckCompilerFlag`](https://gitlab.kitware.com/stephane.albert/vtk/-/commits/CMake-3.19-CheckCompilerFlag) branch of my [fork](https://gitlab.kitware.com/stephane.albert/vtk/). I'm not sure about the correct workflow to create a merge-request etc. and would need some help (all read the development guidelines).
Finally, I created a https://gitlab.kitware.com, forked, added a access token etc., but the _Gitlab_ account seems to be disabled or deleted a few days later since I wasn't able to log in. However, I succeeded to access an account using GMail sign in, but had to regenerate an access token.
Also, when using `git gitlab-push` I got an SSH key error. I then generated one and added the public key to my account, but still had some errors saying that the remote could be read nor written.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18572vtkGeometryFilter does not compile in Debug2022-06-14T19:29:20-04:00Ryan Krattigerryan.krattiger@kitware.comvtkGeometryFilter does not compile in Debug@spiros.tsalikis It looks like the refactor of vtkGeometryFilter changed some class memeber functions to free functions, but didn't change the `vtkDebugMacro` -> `vtkDebugWithObjectMacro` and it no longer compiles.
```
../Filters/Geomet...@spiros.tsalikis It looks like the refactor of vtkGeometryFilter changed some class memeber functions to free functions, but didn't change the `vtkDebugMacro` -> `vtkDebugWithObjectMacro` and it no longer compiles.
```
../Filters/Geometry/vtkGeometryFilter.cxx:2317:3: error: invalid use of 'this' outside of a non-static member function
vtkDebugMacro(<< "Executing geometry filter for poly data input");
^
../Common/Core/vtkSetGet.h:792:50: note: expanded from macro 'vtkDebugMacro'
#define vtkDebugMacro(x) vtkDebugWithObjectMacro(this, x)
```Spiros TsalikisSpiros Tsalikishttps://gitlab.kitware.com/vtk/vtk/-/issues/18567Build failure when building thirdparty mpi4py2023-04-24T16:34:46-04:00Jack·Boos·YuBuild failure when building thirdparty mpi4pyHi guys,
Recently I'm trying to build vtk with internal module mpi4py (https://github.com/microsoft/vcpkg/pull/24740), but I got some failures:
```
FAILED: ThirdParty/mpi4py/vtkmpi4py/src/CMakeFiles/vtkmpi4py.MPI.dir/MPI.c.obj
C:\PROGRA...Hi guys,
Recently I'm trying to build vtk with internal module mpi4py (https://github.com/microsoft/vcpkg/pull/24740), but I got some failures:
```
FAILED: ThirdParty/mpi4py/vtkmpi4py/src/CMakeFiles/vtkmpi4py.MPI.dir/MPI.c.obj
C:\PROGRA~1\MICROS~1\2022\ENTERP~1\VC\Tools\MSVC\1432~1.313\bin\Hostx64\x64\cl.exe -DMPICH_SKIP_MPICXX -DMPI_NO_CPPBIND -DOMPI_SKIP_MPICXX -DPyMPI_MISSING_MPI_Status_c2f -DPyMPI_MISSING_MPI_Status_f2c -DPyMPI_MISSING_MPI_Type_create_f90_complex -DPyMPI_MISSING_MPI_Type_create_f90_integer -DPyMPI_MISSING_MPI_Type_create_f90_real -DVTK_IN_VTK -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_MPICC_H -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -Dvtkmpi4py_MPI_EXPORTS -ID:\buildtrees\vtk\x64-windows-dbg\Utilities\Python -ID:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\Utilities\Python -ID:\buildtrees\vtk\x64-windows-dbg\Common\Core -ID:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\Common\Core -external:ID:\buildtrees\vtk\x64-windows-dbg\Utilities\MPI -external:ID:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\Utilities\MPI -external:ID:\installed\x64-windows\include -external:ID:\buildtrees\vtk\x64-windows-dbg\Utilities\KWIML -external:ID:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\Utilities\KWIML -external:ID:\buildtrees\vtk\x64-windows-dbg\Utilities\KWSys -external:ID:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\Utilities\KWSys -external:ID:\installed\x64-windows\include\python3.10 -external:W0 /nologo /DWIN32 /D_WINDOWS /W3 /utf-8 /MP /bigobj /D_DEBUG /MDd /Z7 /Ob0 /Od /RTC1 -MDd /showIncludes /FoThirdParty\mpi4py\vtkmpi4py\src\CMakeFiles\vtkmpi4py.MPI.dir\MPI.c.obj /FdThirdParty\mpi4py\vtkmpi4py\src\CMakeFiles\vtkmpi4py.MPI.dir\ /FS -c D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\MPI.c
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(154210): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(154212): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(154500): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(154502): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(154880): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(154882): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155076): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155078): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155263): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155265): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155459): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155461): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155678): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155680): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155848): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(155850): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(156863): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(156865): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(157169): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(157171): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(157439): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(157441): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(157612): error C2105: '++' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(157614): error C2105: '--' needs l-value
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(174420): warning C4996: '_PyUnicode_get_wstr_length': deprecated in 3.3
D:\buildtrees\vtk\src\edd2e5233f-2ed574e023.clean\ThirdParty\mpi4py\vtkmpi4py\src\mpi4py.MPI.c(174436): warning C4996: '_PyUnicode_get_wstr_length': deprecated in 3.3
```
Then I searched the same issue by google, and I found the workaround is:
```patch
diff --git a/ThirdParty/mpi4py/vtkmpi4py/src/mpi4py.MPI.c b/ThirdParty/mpi4py/vtkmpi4py/src/mpi4py.MPI.c
index d01c266..9983ac9 100644
--- a/ThirdParty/mpi4py/vtkmpi4py/src/mpi4py.MPI.c
+++ b/ThirdParty/mpi4py/vtkmpi4py/src/mpi4py.MPI.c
@@ -154207,9 +154207,9 @@ static void __pyx_tp_dealloc_6mpi4py_3MPI_Datatype(PyObject *o) {
{
PyObject *etype, *eval, *etb;
PyErr_Fetch(&etype, &eval, &etb);
- ++Py_REFCNT(o);
+ Py_SET_REFCNT(o, Py_REFCNT(o) + 1);
__pyx_pw_6mpi4py_3MPI_8Datatype_3__dealloc__(o);
- --Py_REFCNT(o);
+ Py_SET_REFCNT(o, Py_REFCNT(o) - 1);
PyErr_Restore(etype, eval, etb);
}
(*Py_TYPE(o)->tp_free)(o);
```
It seems that the problem is caused by the wrong version of cpython (or python? maybe).
And I found the mpi4py was updated to 3.1.3 now: https://github.com/mpi4py/mpi4py/tree/master.
Any ideas on this issue?
Thanks,
JackBen BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18552Error when mpi is not selected after installing hdf5[parallel]2022-05-30T03:34:31-04:00Jack·Boos·YuError when mpi is not selected after installing hdf5[parallel]Hi guys,
I'm vcpkg maintainer.
Recently we received an issue about vtk build issues: https://github.com/microsoft/vcpkg/pull/24740.
The issue is:
When you first install hdf5 including feature parallel, and use it as a dependency of vt...Hi guys,
I'm vcpkg maintainer.
Recently we received an issue about vtk build issues: https://github.com/microsoft/vcpkg/pull/24740.
The issue is:
When you first install hdf5 including feature parallel, and use it as a dependency of vtk to install vtk that does not select mpi as a feature, an error will be reported:
```
-- VTK module debug building: VTK::hdf5 is being built
-- Checking for module 'mpi-c'
-- Package 'mpi-c', required by 'virtual:world', not found
-- Checking for module 'mpi-cxx'
-- Package 'mpi-cxx', required by 'virtual:world', not found
CMake Error at ThirdParty/hdf5/CMakeLists.txt:21 (message):
An external MPI-aware HDF5 requires that VTK be built with MPI support as
well.
```
In vcpkg and other package management, dependencies should be forward: if I select a feature in a downstream library, the upstream library should be asked to select the corresponding feature; not that if the upstream library enables a feature, the downstream library must be enabled a corresponding feature.
This has a disastrous effect on dependencies.
What do you guys think about?
How can we "fix" this issue?
Thanks,
Jackhttps://gitlab.kitware.com/vtk/vtk/-/issues/18514libvtkhdf5 contains unmangled symbols2022-04-19T06:49:53-04:00Menno Deij - van Rijswijklibvtkhdf5 contains unmangled symbolsWhen I build paraview with HDF5 coming from VTK/ThirdParty/hdf5, the resulting libvtkhdf5-pv10.so contains many unmangled symbols starting with H5. For example `H5D_def_layout_chunk_g`, which I also find in a build-from-vanilla-source li...When I build paraview with HDF5 coming from VTK/ThirdParty/hdf5, the resulting libvtkhdf5-pv10.so contains many unmangled symbols starting with H5. For example `H5D_def_layout_chunk_g`, which I also find in a build-from-vanilla-source libhdf5.so shared library.
I thought the idea was that no symbol clashes between a loaded vanilla libhdf5 and the libvtkhdf5 shared libraries could occur, thereby enabling another code to have libhdf5 loaded, and also load libvtkhdf5 (maybe as part of in-situ processing) and not have symbols clashing, leading to unpredictable behavior, especially when the two libraries have different versions.
For reference, find attached the results of
`nm libvtkhdf5-pv5.10.so | grep \ vtkhdf5 > libvtkhdf5-mangled.txt`
[libvtkhdf5-mangled.txt](/uploads/b95b058546fa9581bda3a0e6c4678515/libvtkhdf5-mangled.txt)
and `nm libvtkhdf5-pv5.10.so | grep \ H5 > libvtkhdf5-unmangled.txt`
[libvtkhdf5-unmangled.txt](/uploads/48d9e94dd28127b1fb579a2ac3c12fe9/libvtkhdf5-unmangled.txt)
Maybe I'm going about this the wrong way, and this is not a problem.
@utkarsh.ayachit I hope it is OK if I assign this to you, I saw some MR's that also related to symbol mangling of HDF5 with your name on it.Jaswant Panchumarti (Kitware)Jaswant Panchumarti (Kitware)https://gitlab.kitware.com/vtk/vtk/-/issues/18487Configuration error with CMake 3.142022-07-26T21:03:11-04:00Sergey KlevtsovConfiguration error with CMake 3.14Apologies if this has been reported, issue search did not reveal anything.
When trying to configure latest release (9.1.0) with CMake 3.14, the following error occurs (full log is attached):
```
CMake Error at /usr/local/share/cmake-3.1...Apologies if this has been reported, issue search did not reveal anything.
When trying to configure latest release (9.1.0) with CMake 3.14, the following error occurs (full log is attached):
```
CMake Error at /usr/local/share/cmake-3.14/Modules/FindPackageHandleStandardArgs.cmake:195 (message):
Unknown keywords given to FIND_PACKAGE_HANDLE_STANDARD_ARGS():
"REASON_FAILURE_MESSAGE"
Call Stack (most recent call first):
CMake/patches/3.22/FindMPI.cmake:1823 (find_package_handle_standard_args)
CMake/vtkModule.cmake:4397 (find_package)
CMake/vtkModule.cmake:4997 (vtk_module_find_package)
Utilities/MPI/CMakeLists.txt:1 (vtk_module_third_party_external)
-- Configuring incomplete, errors occurred!
```
The error is caused by the following line, which uses a new CMake 3.16 keyword `REASON_FAILURE_MESSAGE`: https://gitlab.kitware.com/vtk/vtk/-/blob/d79e2977b601db1e0592c02b1536f39b6b367314/CMake/patches/3.22/FindMPI.cmake#L1826
The error did not occur in 9.0.3. The change was introduced in https://gitlab.kitware.com/vtk/vtk/-/commit/6343855027c54bed98183d5b4001f02eb1c1b705.
[vtk-9.1.0-cmake-3.14-configure.txt](/uploads/4f9288c4c08a5cba0fa8e5b5d20bbf97/vtk-9.1.0-cmake-3.14-configure.txt)Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18449vtk9.1.0 Emscripten build failed with proj.db and sqlite32023-11-01T10:39:22-04:00勇闯天涯啦vtk9.1.0 Emscripten build failed with proj.db and sqlite3I try to build the vtk-9.1.0 with Emscripten&&CLang follow the cmake-setting propose by [dicehub](https://github.com/dicehub/EmVTK) and [issues/18263](https://gitlab.kitware.com/vtk/vtk/-/issues/18263). But I met the error below.
```
...I try to build the vtk-9.1.0 with Emscripten&&CLang follow the cmake-setting propose by [dicehub](https://github.com/dicehub/EmVTK) and [issues/18263](https://gitlab.kitware.com/vtk/vtk/-/issues/18263). But I met the error below.
```
[1/214] Generating proj.db
FAILED: share/vtk-9.1/proj/proj.db
C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/build-vtk-wasm/share/vtk-9.1/proj/proj.db
cmd.exe /C "cd /D C:\DevTools\vtksource\VTK-9.1.0\Examples\Emscripten\Cxx\work\src\ThirdParty\libproj\vtklibproj\data && "C:\Program Files\CMake\bin\cmake.exe" -E remove -f C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/build-vtk-wasm/lib/../share/vtk-9.1/proj/proj.db && "C:\Program Files\CMake\bin\cmake.exe" -DALL_SQL_IN=C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/build-vtk-wasm/ThirdParty/libproj/vtklibproj/data/all.sql.in -DEXE_SQLITE3=C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/build-vtk-wasm/bin/sqlitebin-9.1.js -DPROJ_DB=C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/build-vtk-wasm/lib/../share/vtk-9.1/proj/proj.db -DPROJ_VERSION=8.1.0 -P C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/src/ThirdParty/libproj/vtklibproj/data/generate_proj_db.cmake && "C:\Program Files\CMake\bin\cmake.exe" -E copy C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/build-vtk-wasm/lib/../share/vtk-9.1/proj/proj.db C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/build-vtk-wasm/ThirdParty/libproj/vtklibproj/data/for_tests"
CMake Error at generate_proj_db.cmake:22 (message):
SQLite3 failed
[2/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/transformations/horner.cpp.o
[3/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/transformations/xyzgridshift.cpp.o
[4/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/transformations/molodensky.cpp.o
[5/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/transformations/deformation.cpp.o
[6/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/transformations/hgridshift.cpp.o
[7/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/transformations/vgridshift.cpp.o
[8/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/iso19111/metadata.cpp.o
[9/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/transformations/tinshift.cpp.o
[10/214] Building CXX object ThirdParty/libproj/vtklibproj/src/CMakeFiles/libproj.dir/transformations/defmodel.cpp.o
ninja: build stopped: subcommand failed.
```
here is my cmake-setting:
```
cmake \
-G Ninja \
-DCMAKE_TOOLCHAIN_FILE=C:/DevTools/emsdk/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake \
-DBUILD_SHARED_LIBS=OFF \
-DCMAKE_BUILD_TYPE=Release \
-DBUILD_EXAMPLES:BOOL=OFF \
-DBUILD_TESTING:BOOL=OFF \
-DVTK_ENABLE_LOGGING=OFF \
-DVTK_ENABLE_WRAPPING=OFF \
-DVTK_GROUP_ENABLE_Imaging=NO \
-DVTK_GROUP_ENABLE_MPI=NO \
-DVTK_GROUP_ENABLE_Qt=NO \
-DVTK_GROUP_ENABLE_Rendering=WANT \
-DVTK_GROUP_ENABLE_StandAlone=WANT \
-DVTK_GROUP_ENABLE_Views=NO \
-DVTK_GROUP_ENABLE_Web=NO \
-DVTK_LEGACY_REMOVE=ON \
-DVTK_NO_PLATFORM_SOCKETS=ON \
-DVTK_MODULE_ENABLE_VTK_hdf5=NO \
-DVTK_MODULE_ENABLE_VTK_InteractionStyle=WANT \
-DVTK_MODULE_ENABLE_VTK_InteractionWidgets=WANT \
-DVTK_MODULE_ENABLE_VTK_RenderingContext2D=DONT_WANT \
-DVTK_MODULE_ENABLE_VTK_RenderingContextOpenGL2=DONT_WANT \
-DOPENGL_INCLUDE_DIR:PATH=C:/DevTools/emsdk/upstream/emscripten/system/include \
-DOPENGL_EGL_INCLUDE_DIR:PATH=C:/DevTools/emsdk/upstream/emscripten/system/include \
-DOPENGL_GLES2_INCLUDE_DIR:PATH=C:/DevTools/emsdk/upstream/emscripten/system/include \
-DOPENGL_GLES3_INCLUDE_DIR:PATH=C:/DevTools/emsdk/upstream/emscripten/system/include \
-DVTK_OPENGL_USE_GLES:BOOL=ON \
-DVTK_USE_SYSTEM_FREETYPE:BOOL=ON \
-DH5_HAVE_GETPWUID:BOOL=OFF \
-DFREETYPE_INCLUDE_DIRS:PATH='include' \
-DFREETYPE_LIBRARY:STRING='freetype' \
C:/DevTools/vtksource/VTK-9.1.0/Examples/Emscripten/Cxx/work/src
cmake --build .
```
where did it go wrong?https://gitlab.kitware.com/vtk/vtk/-/issues/18445Build failure with ffmpeg-5.02022-03-28T16:36:20-04:00BerndBuild failure with ffmpeg-5.0The current v9 releases of VTK won't build their IOFFMPEG module, against an installed ffmpeg-5.0 package. We received a bug report on Gentoo on this for 9.0.3. I tested with 9.1.0 which fails as well.
The error is
```
FAILED: IO/FFMPEG...The current v9 releases of VTK won't build their IOFFMPEG module, against an installed ffmpeg-5.0 package. We received a bug report on Gentoo on this for 9.0.3. I tested with 9.1.0 which fails as well.
The error is
```
FAILED: IO/FFMPEG/CMakeFiles/IOFFMPEG.dir/vtkFFMPEGWriter.cxx.o
/usr/bin/mpicxx -DIOFFMPEG_EXPORTS -DVTK_IN_VTK -D__STDC_CONSTANT_MACROS -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/IO/FFMPEG -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/IO/FFMPEG -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/IO/Movie -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/IO/Movie -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Common/ExecutionModel -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Common/ExecutionModel -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Common/Core -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Common/Core -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Common/DataModel -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Common/DataModel -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Common/Math -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Common/Math -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Common/Transforms -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Common/Transforms -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/IO/Video -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/IO/Video -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Common/Misc -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Common/Misc -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Common/System -I/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Common/System -isystem /var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Utilities/KWIML -isystem /var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Utilities/KWIML -isystem /var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/vtk-9.0.3_build/Utilities/KWSys -isystem /var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/Utilities/KWSys -O2 -march=native -fomit-frame-pointer -pipe -fvisibility-inlines-hidden -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fopenmp -std=c++11 -MD -MT IO/FFMPEG/CMakeFiles/IOFFMPEG.dir/vtkFFMPEGWriter.cxx.o -MF IO/FFMPEG/CMakeFiles/IOFFMPEG.dir/vtkFFMPEGWriter.cxx.o.d -o IO/FFMPEG/CMakeFiles/IOFFMPEG.dir/vtkFFMPEGWriter.cxx.o -c /var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/IO/FFMPEG/vtkFFMPEGWriter.cxx
/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/IO/FFMPEG/vtkFFMPEGWriter.cxx: In member function ‘int vtkFFMPEGWriterInternal::Start()’:
/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/IO/FFMPEG/vtkFFMPEGWriter.cxx:111:41: error: invalid conversion from ‘const AVOutputFormat*’ to ‘AVOutputFormat*’ [-fpermissive]
111 | this->avOutputFormat = av_guess_format("avi", nullptr, nullptr);
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
| |
| const AVOutputFormat*
/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/IO/FFMPEG/vtkFFMPEGWriter.cxx:137:37: error: invalid conversion from ‘const AVCodec*’ to ‘AVCodec*’ [-fpermissive]
137 | if (!(codec = avcodec_find_encoder(this->avOutputFormat->video_codec)))
| ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| const AVCodec*
/var/tmp/portage/sci-libs/vtk-9.0.3-r3/work/VTK-9.0.3/IO/FFMPEG/vtkFFMPEGWriter.cxx:152:32: error: ‘avcodec_alloc_context3’ was not declared in this scope; did you mean ‘avio_alloc_context’?
```
with more errors after that and similar errors later on in file `vtkFFMPEGVideoSource.cxx`.
See also https://bugs.gentoo.org/831595 with a full build log attached.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18429FindPython support uses `cmake_path()` which it should not2022-01-08T20:03:11-05:00David ThompsonFindPython support uses `cmake_path()` which it should notThe CMake support for finding python uses the `cmake_path()` command. This command was introduced in cmake 3.20 which causes problems when build VTK with older versions of cmake. See here
https://gitlab.kitware.com/vtk/vtk/-/blob/1cae65...The CMake support for finding python uses the `cmake_path()` command. This command was introduced in cmake 3.20 which causes problems when build VTK with older versions of cmake. See here
https://gitlab.kitware.com/vtk/vtk/-/blob/1cae6585c3015d754c72f545be983e0e41e6ca17/CMake/patches/3.23/FindPython/Support.cmake#L3053-3055
for the 2 places it is used.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/vtk/vtk/-/issues/18413OpenVDBWriter constructor segfaults with openVDB 92023-12-06T11:45:15-05:00Antonio RojasOpenVDBWriter constructor segfaults with openVDB 9This minimal example
```
#include <vtk/vtkOpenVDBWriter.h>
int main() {
vtkOpenVDBWriter* a=vtkOpenVDBWriter::New();
}
```
segfaults with openVDB 9 with this backtrace:
```
(gdb) bt
#0 openvdb::v9_0::Grid<openvdb::v9_0::tree::Tree<...This minimal example
```
#include <vtk/vtkOpenVDBWriter.h>
int main() {
vtkOpenVDBWriter* a=vtkOpenVDBWriter::New();
}
```
segfaults with openVDB 9 with this backtrace:
```
(gdb) bt
#0 openvdb::v9_0::Grid<openvdb::v9_0::tree::Tree<openvdb::v9_0::tree::RootNode<openvdb::v9_0::tree::InternalNode<openvdb::v9_0::tree::InternalNode<openvdb::v9_0::tree::LeafNode<openvdb::v9_0::ValueMask, 3u>, 4u>, 5u> > > >::gridType[abi:cxx11]()
() at /usr/src/debug/openvdb-9.0.0/openvdb/openvdb/Grid.h:719
#1 openvdb::v9_0::Grid<openvdb::v9_0::tree::Tree<openvdb::v9_0::tree::RootNode<openvdb::v9_0::tree::InternalNode<openvdb::v9_0::tree::InternalNode<openvdb::v9_0::tree::LeafNode<openvdb::v9_0::ValueMask, 3u>, 4u>, 5u> > > >::registerGrid ()
at /usr/src/debug/openvdb-9.0.0/openvdb/openvdb/Grid.h:981
#2 openvdb::v9_0::initialize () at /usr/src/debug/openvdb-9.0.0/openvdb/openvdb/openvdb.cc:100
#3 0x00007ffff7e1da25 in vtkOpenVDBWriter::vtkOpenVDBWriter (this=0x55555558a050)
at /usr/src/debug/VTK-9.1.0/IO/OpenVDB/vtkOpenVDBWriter.cxx:365
#4 0x00007ffff7e1dabe in vtkOpenVDBWriter::New () at /usr/src/debug/VTK-9.1.0/IO/OpenVDB/vtkOpenVDBWriter.cxx:357
#5 0x0000555555555166 in main ()
```https://gitlab.kitware.com/vtk/vtk/-/issues/18379VTK 9.1.0 does not compile with Qt52022-01-10T05:28:03-05:00Billy AraujoVTK 9.1.0 does not compile with Qt5GUISupport/QtQuick/QQuickVTKInteractorAdapter.cxx does not compile with Qt5.11.2.
```
//-------------------------------------------------------------------------------------------------
void QQuickVTKInteractorAdapter::QueueWheelEvent(...GUISupport/QtQuick/QQuickVTKInteractorAdapter.cxx does not compile with Qt5.11.2.
```
//-------------------------------------------------------------------------------------------------
void QQuickVTKInteractorAdapter::QueueWheelEvent(QQuickItem* item, QWheelEvent* e)
{
QPointF p, gp;
#if QT_VERSION >= QT_VERSION_CHECK(5, 14, 0)
p = e->position();
gp = e->globalPosition();
#else
p = e->posF();
gp = e->globalPosF();
#endif
QWheelEvent* newEvent = new QWheelEvent(this->mapEventPosition(item, p),
this->mapEventPosition(item, gp), e->pixelDelta(), e->angleDelta(), e->buttons(),
e->modifiers(), e->phase(), e->inverted(), e->source());
QueueEvent(newEvent);
}
```
This seems to only work for Qt 6 as this is the signature of the new constructor.
`QWheelEvent(const QPointF &pos, const QPointF &globalPos, QPoint pixelDelta, QPoint angleDelta, Qt::MouseButtons buttons, Qt::KeyboardModifiers modifiers, Qt::ScrollPhase phase, bool inverted, Qt::MouseEventSource source = Qt::MouseEventNotSynthesized, const QPointingDevice *device = QPointingDevice::primaryPointingDevice())`
In Qt 5 it was:
`QWheelEvent(const QPointF &pos, const QPointF &globalPos, QPoint pixelDelta, QPoint angleDelta, int qt4Delta, Qt::Orientation qt4Orientation, Qt::MouseButtons buttons, Qt::KeyboardModifiers modifiers, Qt::ScrollPhase phase, Qt::MouseEventSource source, bool inverted)`
So I doubt this compiles on any Qt5 version. All VTK compiles on Qt5 except for this line so this should be fixed as many people are not using Qt6.
Also shouldn't this type of thing be caught by the CI system? Doesn't it build and test with Qt5 and Qt6?https://gitlab.kitware.com/vtk/vtk/-/issues/18310H5detect vs H5Tinit.c dependency problem2021-09-23T15:32:40-04:00David GobbiH5detect vs H5Tinit.c dependency problemSystem: macOS 10.15, cmake 3.13.2, GNU make 3.81, VTK master from Sept 15, 2021
Doing a "Makefile" build (-j 1) of VTK generated this error:
```text
No rule to make target 'ThirdParty/hdf5/vtkhdf5/src/H5Tinit.c'
```
The build continued ...System: macOS 10.15, cmake 3.13.2, GNU make 3.81, VTK master from Sept 15, 2021
Doing a "Makefile" build (-j 1) of VTK generated this error:
```text
No rule to make target 'ThirdParty/hdf5/vtkhdf5/src/H5Tinit.c'
```
The build continued after I forced H5detect to build:
```bash
make H5detect
make
```
I haven't dug very deep into this, but the following code block [(line 1084 in ThirdParty/hdf5/vtkhdf5/src/CMakeLists.txt)](https://gitlab.kitware.com/vtk/vtk/-/blob/7591e63b/ThirdParty/hdf5/vtkhdf5/src/CMakeLists.txt#L1084) seems to be implicated:
```cmake
add_custom_command (TARGET H5detect POST_BUILD
COMMAND ${CMAKE_CROSSCOMPILING_EMULATOR} $<TARGET_FILE:H5detect>
ARGS H5Tinit.c
BYPRODUCTS H5Tinit.c gen_SRCS.stamp1
COMMAND ${CMAKE_COMMAND}
ARGS -E touch gen_SRCS.stamp1
DEPENDS H5detect
WORKING_DIRECTORY ${HDF5_GENERATED_SOURCE_DIR}
COMMENT "Create H5Tinit.c"
)
```
Perhaps the problem is the use of "BYPRODUCTS" with no "OUTPUT" with the Makefile generator?
There seem to be similar dependency issues with `H5lib_settings.c` and `H5make_libsettings`. In that case, the workaround was this:
```
make H5make_libsettings
```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 lasthttps://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/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/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/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/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/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/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 Boeckel