Remaining build issues on crossroads

[markcmiller86]

Describe the bug

• [x] CMake 3.24 fails to fully configure itself due to unreliable logic testing for C++11 constructs (make unique, std::unique_ptr, std::filesystem).
  • There is a clock skew problem on this system so make winds up emitting warning messages. Ordinarily, I see this only for parallel makes and the solution is a -j 1 for make jobs. However, that still doesn't fix this issue on crossroads.
  • Those warnings are interpreted by CMake as failures for the tested C++11 constructs. There is a slew of filtering done in Sources/Checks/cm_cxx_features.cmake, and it seems more needs to be added all the time as new cases are encountered.
  • We need to set...
    • -DCMake_HAVE_CXX_MAKE_UNIQUE:BOOL=ON
    • -DCMake_HAVE_CXX_UNIQUE_PTR:BOOL=ON
    • -DCMake_HAVE_CXX_FILESYSTEM:BOOL=ON to work around this issue.
• [ ] Ospray now uses a superbuild. That tries to download .zip files with either sources or pre-compiled binaries for embree, rkcommon, tbb, ispc, glm, openvkl. Some of these have relevant top-level CMake variables we should set as follows...
  • DOWNLOAD_ISPC:BOOL=OFF
  • DOWNLOAD_TBB:BOOL=OFF
  • BUILD_EMBREE_FROM_SOURCE:BOOL=ON
  • BUILD_ISPCRT_FROM_SOURCE:BOOL=ON
  • BUILD_TBB_FROM_SOURCE:BOOL=ON In addition, we need to investigate use of RKCOMMON_TASKING_SYSTEM:STRING= which can be set to TBB, OpenMP and Internal. Also we need to find the right place to stuff the requisite .zip files that we cannot avoid downloading so that ospray will not attempt to download them.
• [ ] My default login is a tcsh shell. The module command there is an alias. The run-build-visit script is a bash script which launches in a sub-shell. The module commands there wind up silently failing. One has to have performed all the module work in the invoking shell first.
• [ ] Should we try to get adios, adios2 and mili database plugins working there. They are currently disabled.
• [ ] The run-build-visit script may need to newgrp visit before attempting to install to a public place.
• [ ] I wound up disabling ospray and icet due to build issues and those need to be re-enabled
• [ ] The VisIt build fails with same issue as reported in #19336...solution is to use Qt5.10
• [ ] I tried to copy the whole git repos over to crossroads for visit-dav, third-party and visit-website (the latter with hope of possibly standing up a VisIt website on SCF). Getting this right is tricky and in future it might make sense to use git bundle. That said, here is the process...
  • git clone the repo
  • git lfs pull (git lfs fetch --all might be better but it will download all versions to begining of time and not necessary)
  • git submodule init; git submodule update
  • tar everything up but don't bother with compression. The git repo is already fairly well compressed and you'll just waste time for little reduction in size.
• Building VTK8 with Python 3.9 requires this patch
• [ ] conduit v.91 + cmake 3.24 seems to insist on mpi compiler wrappers. I could not specify paths to gnu compilers and then also includes and libs for mpi manually.
• [ ] For some reason, after building the viewer could not find some VTK libs. ldd reported them as not found. I had to manually set LD_LIBRARY_PATH to include the VTK installation.
• [ ] We appear to require MFEM 4.6 but that is no where to be found in either third_party/lib or release assets for 3.4.0 for third_party. We're successfully always downloading it from bit.ly when we've been building.

[cyrush]

Which gcc compiler are we trying there?

If it's too new maybe that could be tripping up cmake.

Maybe we can try an older one?

[markcmiller86]

Which gcc compiler are we trying there?

11.2.0, same as was on trinity

[markcmiller86]

The problem isn't the compiler. its the filesystem there. That is causing timestamps on various files to not quite line up. So, some files are seen as having been modified in the future. Normally, parallel make is the cause of this and -j 1 fixes. But, I tried that to no avail. The filesystem winds up causing operations in CMake's bootstrap to emit warnings. Those warnings get interpreted by CMake's bootstrapping logic as you can see here... https://github.com/Kitware/CMake/blob/1d52195b96140dab76678cfa541c540bda654b9c/Source/Checks/cm_cxx_features.cmake#L60-L63

[biagas]

I wonder if a newer cmake would work better on this system?

[markcmiller86]

The issue with Qt6 on crossroads is that libxkbcommon-x11 is not present. I reverted to building qt510 there. There are system builds for qt 5.15.5 and 6.5.1 there but I don't think either has OpenGL enabled and libxkbcommon-x11 is not present in the later.

• I discovered that even if boost is already installed, if the build dir for boost is removed, it thinks it is not installed.
• The qt510 patch for centos should not be an os-specific patch. It patches a basically broken conflict between static and extern declarations which is a problem for any compiler that bothers to flag it. Adding -fpermissive to CFLAGS and CXXFLAGS may work (though it is drastic measure) but there is already patching logic there and it should be applied always.
• I discovered that re-application of a patch (which patch detects and says is "harmless") can cause a build to fail if it winds up early returning from patches that follow. I don't know how prevalent this is in build_visit in general but I discovered it hacking on bv_qt.sh.

[cyrush]

Make sure run-build-visit is update with crossroads (remove trinity)