Windows build errors with cmb-superbuild:master VS2019

  1. There was a recent change to the common superbuild that deleted a file qt.package.cmake, however that file is included by qt5.system.cmake. I’ll paste the console messages below showing the configure error. Can the include just be removed from qt5.system.cmake?
    Building projects: cxx11, boost, eigen, zlib, szip, hdf5, netcdf, moab, zeromq, remus, png, vxl, nlohmannjson, python3, python, ftjam, freetype, gdal, las, qt5, paraview, pybind11, bzip2, libarchive, pegtl, smtk, cmbworkflows, cmbusersguide, smtkprojectmanager, smtkresourcemanagerstate, cmb
    CMake Error at superbuild/projects/win32/qt5.system.cmake:4 (include):
      include could not find load file:

    Call Stack (most recent call first):
      superbuild/cmake/SuperbuildMacros.cmake:919 (include)
      superbuild/CMakeLists.txt:155 (superbuild_process_dependencies)

    -- Configuring incomplete, errors occurred!
  1. Yes, it looks like we can just remove that line from qt5.system.cmake. After that, building proceeds through smtk. Next issue is configuring smtkresourcemanagerstate, which cannot find python.

    CMake Error at C:/Program Files/CMake/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
    Could NOT find Python3 (missing: Python3_LIBRARY Python3_INCLUDE_DIR
    Development) (Required is at least version “3.7”)
    Call Stack (most recent call first):
    C:/Program Files/CMake/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
    C:/Users/johnt/Documents/ace3p/build/full-superbuild/install/lib/cmake/paraview-5.7/vtk/patches/99/FindPython/Support.cmake:1870 (find_package_handle_standard_args)
    C:/Users/johnt/Documents/ace3p/build/full-superbuild/install/lib/cmake/paraview-5.7/vtk/patches/99/FindPython3.cmake:256 (include)
    C:/Users/johnt/Documents/ace3p/build/full-superbuild/install/lib/cmake/paraview-5.7/vtk/VTK-vtk-module-find-packages.cmake:456 (find_package)
    C:/Users/johnt/Documents/ace3p/build/full-superbuild/install/lib/cmake/paraview-5.7/vtk/vtk-config.cmake:130 (include)
    C:/Users/johnt/Documents/ace3p/build/full-superbuild/install/lib/cmake/paraview-5.7/paraview-config.cmake:53 (find_package)
    C:/Users/johnt/Documents/ace3p/build/full-superbuild/install/cmake/smtk/3.3.0/smtkConfig.cmake:103 (find_package)
    CMakeLists.txt:13 (find_package)

    – Configuring incomplete, errors occurred!
    See also “C:/Users/johnt/Documents/ace3p/build/full-superbuild/superbuild/smtkresourcemanagerstate/build/CMakeFiles/CMakeOutput.log”.
    See also “C:/Users/johnt/Documents/ace3p/build/full-superbuild/superbuild/smtkresourcemanagerstate/build/CMakeFiles/CMakeError.log”.
    CMake Error at C:/Users/johnt/Documents/ace3p/build/full-superbuild/superbuild/sb-smtkresourcemanagerstate-configure.cmake:47 (message):
    Failed with exit code 1

3. Disable smtkresourcemanagerstate and you get the same error with smtkprojectmanager – unabled to configure because pythonb not found.

I should note that smtkprojectmanager doesn’t use/require python. I presume the error occurs when processing smtk’s config file?

With nothing to lose, I also tried adding python as an explicit dependency in smtkprojectmanager.cmake, but the same error occurs configuring smtkprojectmanager.

  1. After disabling smtkprojectmanager, the next error occurs building cmb, specifically, linking modelbuilder, where there is a problem with the python dll.

    [22/22] Linking CXX executable bin\modelbuilder.exe
    FAILED: bin/modelbuilder.exe
    cmd.exe /C “cd . && “C:\Program Files\CMake\bin\cmake.exe” -E vs_link_exe --intdir=modelbuilder\CMakeFiles\modelbuilder.dir --rc=“C:\PROGRA~2\Windows Kits\10\bin\10.0.18362.0\x64\rc.exe” --mt=“C:\PROGRA~2\Windows Kits\10\bin\10.0.18362.0\x64\mt.exe” --manifests – “C:\PROGRA~2\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.23.28105\bin\Hostx64\x64\link.exe” /nologo @CMakeFiles\modelbuilder.rsp /out:bin\modelbuilder.exe /implib:lib\modelbuilder.lib /pdb:bin\modelbuilder.pdb /version:0.0 /machine:x64 /INCREMENTAL:NO /subsystem:windows && cd .”
    LINK: command “C:\PROGRA~2\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.23.28105\bin\Hostx64\x64\link.exe /nologo @CMakeFiles\modelbuilder.rsp /out:bin\modelbuilder.exe /implib:lib\modelbuilder.lib /pdb:bin\modelbuilder.pdb /version:0.0 /machine:x64 /INCREMENTAL:NO /subsystem:windows /MANIFEST /MANIFESTFILE:bin\modelbuilder.exe.manifest” failed (exit code 1107) with the following output:
    C:\Users\johnt\Documents\ace3p\build\full-superbuild\install\Python\python37.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2F8
    ninja: build stopped: subcommand failed.
    CMake Error at C:/Users/johnt/Documents/ace3p/build/full-superbuild/superbuild/sb-cmb-build.cmake:47 (message):
    Failed with exit code 1

Another observation that was unexpected: some of the project config files are written to <install>/cmake instead of <install>/lib/cmake.

$  ll /c/Users/johnt/Documents/ace3p/build/full-superbuild/install/cmake
total 45
-rw-r--r-- 1 johnt 197121 1308 Dec  6 21:46 BZip2Config.cmake
-rw-r--r-- 1 johnt 197121 3201 Dec  6 21:46 BZip2ConfigInternal.cmake
-rw-r--r-- 1 johnt 197121  857 Dec  6 21:46 BZip2ConfigInternal-release.cmake
-rw-r--r-- 1 johnt 197121 1773 Dec  6 21:46 BZip2ConfigVersion.cmake
drwxr-xr-x 1 johnt 197121    0 Dec  6 22:06 hdf5/
-rw-r--r-- 1 johnt 197121 1358 Dec  6 22:20 liblas-config.cmake
-rw-r--r-- 1 johnt 197121 1803 Dec  6 22:20 liblas-config-version.cmake
-rw-r--r-- 1 johnt 197121 3162 Dec  6 22:20 liblas-depends.cmake
-rw-r--r-- 1 johnt 197121 1526 Dec  6 22:20 liblas-depends-release.cmake
drwxr-xr-x 1 johnt 197121    0 Dec  7 04:30 Remus/
drwxr-xr-x 1 johnt 197121    0 Dec  7 00:14 smtk/
-rw-r--r-- 1 johnt 197121 3478 Dec  6 21:48 szip-config.cmake
-rw-r--r-- 1 johnt 197121  683 Dec  6 21:48 szip-config-version.cmake
-rw-r--r-- 1 johnt 197121 3469 Dec  6 21:48 szip-targets.cmake
-rw-r--r-- 1 johnt 197121 1317 Dec  6 21:48 szip-targets-release.cmake

This isn’t surprising. CMake looks in different places depending on the platform. There’s no one place that all platforms look :frowning: .

Hmm. Something is putting the python DLL in the Python_LIBRARY field. This is wrong; it should be the python37.lib that goes there.

For now, I am going to put this thread on HOLD, because I can move to a docker-based environment on Haocheng’s old laptop.

  • I will shortly be starting a new topic for windows/docker build issues with cmb-superbuild:master vs2019
  • And I wish I could somehow mark this topic as “old” or obsolete…