This is Ubuntu 20.04.2 LTS / x86_64 / gcc 9.3.0 here.
I built the “VTK-9.0.3”.
The “make test” reports: “2116 - VTKExample-Infovis/Cxx (Skipped)”
Looking into the “Examples/Infovis/Cxx/CMakeLists.txt” file, I find that all required (and also all optional) VTK package components were built.
So, I cannot find the reason why the “Infovis” examples cannot be built (I tried to build them “manually”, too).
What could be the reason?
The following “Infovis” related modules (shared libraries) were built: “InfovisBoostGraphAlgorithms”, “InfovisCore”, “InfovisLayout”, “IOInfovis”, “ViewsInfovis”.
The initial VTK cmake step does find “Boost”, including the “Boost::serialization” component (after “sudo apt-get install libboost-all-dev”): -- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found version "1.71.0") found components: serialization
However, the “InfovisBoost” module was NOT built (even though I configured VTK adding “-DVTK_MODULE_ENABLE_VTK_InfovisBoost=YES”).
What could be the reason?
Finally, the “make test” reports that 32 tests failed out of 2122. I do not know if these are “known issues” or if there are real problems somewhere (Python 3.8.10 is used):
There are the -DVTK_MODULE_DEBUG=ON -DVTK_MODULE_DEBUG_ALL=ON flags you can pass to have VTK’s module system dump out its consideration of every module. I would recommend looking at that to see if it gives any insight into why the module might not be available. That said, I don’t know what would cause it to ignore its VTK_MODULE_ENABLE flag off hand.
It seems everything is fine with the “InfovisBoost” module.
Sorry for misleading you.
I rebuilt VTK, adding “-DVTK_DEBUG_MODULE=ON -DVTK_DEBUG_MODULE_ALL=ON”.
The initial VTK cmake step reported: -- VTK module debug building: VTK::InfovisBoost is being built
And I now also noted that “make test” reported: 296/2122 Test #296: VTK::InfovisBoostCxx-TestVariantSerialization ................................................ Passed 0.06 sec VTK::InfovisBoost = 0.06 sec*proc (1 test) vtkInfovisBoost = 0.06 sec*proc (1 test)
It looks like I had false expectations.
The “Infovis/Boost/vtk.module” file contains “LIBRARY_NAME vtkInfovisBoost”.
So, I expected that there would appear a “libvtkInfovisBoost-9.0.so.9.0.3” file.
No such library was built.
On the other hand, the “Infovis/Boost/CMakeLists.txt” file contains “vtk_module_add_module(VTK::InfovisBoost ... HEADER_ONLY)” (and indeed, the “vtkVariantBoostSerialization.h” file is present in the “include/vtk-9.0” directory after “make install”).
So, most probably, no shared library related to this module is expected to be built at all.
Am I right now?
This still leaves the problem of the skipped “VTKExample-Infovis/Cxx” test.
Do you know any magic flags which would “dump” some info on why this happens?
No matter what I try, I get no single message in the form “VTK_${component}_*FOUND*” when I try to build the “Examples/Infovis/Cxx”.
The cmake step ends with no errors, but it produces a “dummy” makefile (running “make” simply returns “Nothing to be done for 'all'.”).
set(vtk_modules # the "set" BEGINS here
find_package(VTK # the "find_package" BEGINS here
COMPONENTS
FiltersSources
...
RenderingOpenGL2) # the "find_package" ENDS here ...
OPTIONAL_COMPONENTS # ... what is this then?
FiltersStatistics
...
ViewsQt) # the "set" ENDS here
Is the “set” expected to execute commands that compute its arguments? I cannot find such a statement in the “set” documentation.
Is the “find_package” expected to return a list of packages? I cannot find such a statement in the “find_package” documentation.
Hmm. That’s a good question. That does indeed seem to be very wrong. I don’t know why there’s no error since it is invalid CMake syntax. I suspect it is leftover from copy pasta. Feel free to hack it up to remove the set(vtk_modules line and the extra ) before OPTIONAL_COMPONENTS. That should get a better result.
Two executables cannot be linked: “Examples/Infovis/Cxx/EasyView” and “Examples/Infovis/Cxx/CustomLinkView”.
In both cases the “vtkDataObjectToTable::New()” is missing:
/usr/bin/ld: CMakeFiles/EasyView.dir/EasyView.cxx.o: undefined reference to symbol '_ZN20vtkDataObjectToTable3NewEv' /usr/bin/ld: CMakeFiles/CustomLinkView.dir/CustomLinkView.cxx.o: undefined reference to symbol '_ZN20vtkDataObjectToTable3NewEv' /usr/bin/ld: /.../lib/libvtkInfovisCore-9.0.so.1: error adding symbols: DSO missing from command line
Ah, yes. I forgot that there were “CMakeLists.txt” files in every subdirectory (which were using the broken “vtk_modules” variable). The strange thing was that the “Examples/Infovis/Cxx/StatsView” was built without problems.
Anyhow, I now rebuilt the whole VTK with your new patches, and all “Examples/Infovis/Cxx” executables are there (and the test said “Passed”).
Of course, there are still 32 tests that failed out of 2122 (the same as shown in my first post above).
The easiest is ctest --rerun-failed -VV (assuming that these are the failing tests from the last ctest run). Alternatively, you can use ctest to submit to the dashboard with ctest -M Experimental -T Test --rerun-failed followed by ctest -M Experimental -T Submit. Finding the entry on CDash and linking to it would also make the baseline image differences available.
I am attaching a file with my “failed tests” results.
Inside, you can find the “ctest_rerun_failed_VV.out.txt” file with a complete log from running the “ctest --rerun-failed -VV” command.
Out of the 32 tests that “failed” …
In 8 cases, “mpiexec” related tests die with an error: “There are not enough slots available in the system to satisfy the __SOME_NUMBER_ slots that were requested by the application”.
UPDATE: I added a “localhost slots=8” line in the “/etc/openmpi/openmpi-default-hostfile” file, and then all 8 “VTK::FiltersParallel*-MPI-*” tests run fine (i.e., “Passed”).
In 23 cases, a “.diff.png” file has been generated (all of them are also included in the attached file).
One case (test 1042) reports that “image differencing failed” due to different sizes. I think what happened is that my laptop’s screen is only 1600x900, and the original image is 800x900, so it got cut to 800x875 when running this test on my laptop (X11 “window decorations” used 25 pixels).
I think filing an issue with the information is the best bet right now. I don’t know how much attention any hypothetical 9.0.4 might get. But, if the problems persist on master, then it is of much more interest.
. Thanks for testing.