Hi all, I am hearing reports from some people on Windows that Boost 1.70 is needed to build with VS 2019. Does anyone have objections to moving the SMTK/CMB superbuild to boost 1.70?
1 Like
+1
1 Like
Note that MSVC 15.0 does not exist as coded here
https://gitlab.kitware.com/paraview/common-superbuild/blob/master/projects/win32/boost.cmake#L19
see : https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B
I have a version of this file I use that properly constructs the msvc_ver per the MSVC_TOOLSET_VERSION as FindBoost.cmake does in CMake
Also note that remus seemed to have link issue on windows with boost 1.70
Sounds like a great MR! 
@aron.helser and I worked through that yesterday by modifying projects/cmb.cmake so that remus and zeromq were not dependencies of modelbuilder. We will eventually need remus for aeva, but not quite yet — and in any event, that dependency really shouldn’t be there; we need to pull out the part of SMTK that does external meshing into a new library and make that depend on remus.
Note another oddity I found (on windows) is that the build seems to put the boost dlls in the install/lib dir at first, then eventually they also end up in the install/bin. There is no reason for the dlls to be in the lib dir on windows.
ALSO, it seems something else is building boost as I actually have 2 boost dlls for each component, for example :
- boost_atomic-vc141-mt-gd-x64-1_66.dll
- boost_atomic-vc141-mt-x64-1_66.dll
the gd means debug, but this is a release ninja build (using the msvc 2017 compiler)
+1
This copying is done in superbuild/projects/win32/scripts/boost.copylibs.cmake. Boost’s own build system is putting the files in the wrong location. The superbuild is trying to leave boost alone and just work around it.
I couldn’t find what was generating the debug build of boost, but that may be another thing Boost’s bjam system does automatically.
I’m working to find to determine if we can move to VS 2019. Right now we use 2017 and passing -vcvars_ver=14.0
duh. My bad 