default cmake values except USE_SYSTEM_qt5, which is set to qt.io 5.12.6 binaries
There are 2 separate errors in the configure-remus step.
1. Unable to find the boost components. From the command prompt (console):
-- Found Threads: TRUE
CMake Error at C:/Program Files/CMake/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
Could NOT find Boost (missing: thread chrono filesystem system date_time)
(found suitable version "1.66.0", minimum required is "1.48.0")
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
C:/Program Files/CMake/share/cmake-3.16/Modules/FindBoost.cmake:2165 (find_package_handle_standard_args)
CMakeLists.txt:75 (find_package)
-- Configuring incomplete, errors occurred!
2. The remus CMakeError.log file is also non-empty with a different error message:
Determining if the include file pthread.h exists failed with the following output:
Change Dir: C:/Users/IEUser/Documents/build/release-superbuild/superbuild/remus/build/CMakeFiles/CMakeTmp
Run Build Command(s):C:/Users/IEUser/bin/ninja.exe cmTC_9cf5d && [1/2] Building C object CMakeFiles\cmTC_9cf5d.dir\CheckIncludeFile.c.obj
FAILED: CMakeFiles/cmTC_9cf5d.dir/CheckIncludeFile.c.obj
C:\PROGRA~2\MICROS~2\2017\COMMUN~1\VC\Tools\MSVC\1416~1.270\bin\Hostx64\x64\cl.exe /nologo /DWIN32 /D_WINDOWS /W3 /MDd /Zi /Ob0 /Od /RTC1 /showIncludes /FoCMakeFiles\cmTC_9cf5d.dir\CheckIncludeFile.c.obj /FdCMakeFiles\cmTC_9cf5d.dir\ /FS -c CheckIncludeFile.c
CheckIncludeFile.c(1): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory
ninja: build stopped: subcommand failed.
The error output is a red herring; all try_compile code goes there. That’s the output saying "pthread.h is not present" which is OK on Windows.
The first means that FindBoost isn’t finding the libraries. There are some debugging options to get FindBoost to be more chatty. What output do you get if you add those flags?
The problem is the VC toolset. I’ll paste some of the console messages from configuring remus with Boost_DEBUG (cannot upload text file to discourse?), but the short version is that FindBoost when configuring remus is looking for vc140 or vc141 boost libs, but VS2017 is generating vc150 boost libs.
I am using Visual Studio Community 2017, Version 15.9.7, which I think is the latest.
CMake reports the MSCV_VERSION as 1916, which should generate vc141 files according to CMake docs.
I see there was a commit on common-superbuild:master to update win32/boost.cmake Nov 11 ( link ) for VS 2019. That commit still doesn’t look consistent with the CMake page for MSVC_VERSION, so I am going to addlib my own mod and try that next.
– [ C:/Program Files/CMake/share/cmake-3.16/Modules/FindBoost.cmake:2044 ] Searching for SYSTEM_LIBRARY_RELEASE: boost_system-vc141-mt-x64-1_66;boost_system-vc141-mt-x64;boost_system-vc141-mt;boost_system-vc140-mt-x64-1_66;boost_system-vc140-mt-x64;boost_system-vc140-mt;boost_system-mt-x64-1_66;boost_system-mt-x64;boost_system-mt;boost_system-mt;boost_system
– [ C:/Program Files/CMake/share/cmake-3.16/Modules/FindBoost.cmake:2099 ] Searching for SYSTEM_LIBRARY_DEBUG: boost_system-vc141-mt-gd-x64-1_66;boost_system-vc141-mt-gd-x64;boost_system-vc141-mt-gd;boost_system-vc140-mt-gd-x64-1_66;boost_system-vc140-mt-gd-x64;boost_system-vc140-mt-gd;boost_system-mt-gd-x64-1_66;boost_system-mt-gd-x64;boost_system-mt-gd;boost_system-mt;boost_system
– [ C:/Program Files/CMake/share/cmake-3.16/Modules/FindBoost.cmake:2044 ] Searching for DATE_TIME_LIBRARY_RELEASE: boost_date_time-vc141-mt-x64-1_66;boost_date_time-vc141-mt-x64;boost_date_time-vc141-mt;boost_date_time-vc140-mt-x64-1_66;boost_date_time-vc140-mt-x64;boost_date_time-vc140-mt;boost_date_time-mt-x64-1_66;boost_date_time-mt-x64;boost_date_time-mt;boost_date_time-mt;boost_date_time
– [ C:/Program Files/CMake/share/cmake-3.16/Modules/FindBoost.cmake:2099 ] Searching for DATE_TIME_LIBRARY_DEBUG: boost_date_time-vc141-mt-gd-x64-1_66;boost_date_time-vc141-mt-gd-x64;boost_date_time-vc141-mt-gd;boost_date_time-vc140-mt-gd-x64-1_66;boost_date_time-vc140-mt-gd-x64;boost_date_time-vc140-mt-gd;boost_date_time-mt-gd-x64-1_66;boost_date_time-mt-gd-x64;boost_date_time-mt-gd;boost_date_time-mt;boost_date_time
– [ C:/Program Files/CMake/share/cmake-3.16/Modules/FindBoost.cmake:2044 ] Searching for ATOMIC_LIBRARY_RELEASE: boost_atomic-vc141-mt-x64-1_66;boost_atomic-vc141-mt-x64;boost_atomic-vc141-mt;boost_atomic-vc140-mt-x64-1_66;boost_atomic-vc140-mt-x64;boost_atomic-vc140-mt;boost_atomic-mt-x64-1_66;boost_atomic-mt-x64;boost_atomic-mt;boost_atomic-mt;boost_atomic
– [ C:/Program Files/CMake/share/cmake-3.16/Modules/FindBoost.cmake:2099 ] Searching for ATOMIC_LIBRARY_DEBUG: boost_atomic-vc141-mt-gd-x64-1_66;boost_atomic-vc141-mt-gd-x64;boost_atomic-vc141-mt-gd;boost_atomic-vc140-mt-gd-x64-1_66;boost_atomic-vc140-mt-gd-x64;boost_atomic-vc140-mt-gd;boost_atomic-mt-gd-x64-1_66;boost_atomic-mt-gd-x64;boost_atomic-mt-gd;boost_atomic-mt;boost_atomic
CMake Error at C:/Program Files/CMake/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
Could NOT find Boost (missing: thread chrono filesystem system date_time)
(found suitable version “1.66.0”, minimum required is “1.48.0”)
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
C:/Program Files/CMake/share/cmake-3.16/Modules/FindBoost.cmake:2165 (find_package_handle_standard_args)
CMakeLists.txt:75 (find_package)
My apologies to everyone tracking this. I had completely forgotten about the “command line length” problem on windows, so I had to restart from scratch in a new directory with a darn-short path (I used C:\cmb\bld).
The good news is that, YES, cmb:release builds in the new folder. So either the longer paths were screwing things up or maybe I needed to do a completely clean build (?)
Just so I don’t forget, this still requires my one-line mod to the win32/boost.cmake file in common-superbuild (setting msvc_ver to 14.1 for MSCV_VERSION < 1920).
I’m not completely done, however. Packaging fails to install the cmbPostProcessingPlugin because the Qt libs cannot be found. I’ll paste the console message below. I have some recollection this was previously fixed for Linux and/or macOS, so maybe there is an easy fix.
Looking at why fixup_bundle fails for the cmbPostProcessing plugin, I can see that the cmake_install.cmake file generated at cpack/modelbuilder/ZIP/build includes the Qt path for modelbuilder but not cmbPostProcessingPlugin. @ben.boeckel can you tell me where that file gets generated?
When the packaging test gets to cmb.bundle.windows.cmake, the library paths passed in to superbuild_windows_install_plugin() look correct to me, but these paths don’t show up in what gets passed to fixup_bundle. So I am trying to figure out where the disconnect is.
FYI adding some printf’s to cmb.bundle.windows.cmake (staring at line 80):
is necessary in the superbuild’s top-level CMakeCache.txt file to prevent multiple build issues. (The /EHsc prevents errors related to boost::exception, the /DWIN32 is required or MOAB will complain that strcasecmp() is missing.)
<rant>We need to commit superbuild changes so Windows builds work for everyone without resorting to docker images or research on the Discourse forum. </rant>
.