Closed ye-luo closed 4 days ago
Test this please
I don't think I've touched a boost tarball for a decade. Either it is a distro package or I use spack. And at least for spack I had to pull a newer version of spack and reinstall boost. My old install did not include the cmake config files for any version of spack. I can see the recipe for boost has been updated. So I think that's probably a possible issue here.
Once I've done that it works fine. I don't think spack was ever correct to leave these files out.
I'd add I'm using cmake@3.29.2 was using boost@1.86.0 installed months ago and reinstalled after a pull of spack develop today. So this works with older cmake's but maybe not if you have a old spack install of boost even if its far newer that 1.70
On osx homebrew looks to be installing boost properly.
(Not changing my view here - needs updating to use the new find_package mechanisms for cmake >=3.30.0 otherwise use the old scheme. This is the least disruptive approach.)
@PDoakORNL boost issue fixed by https://github.com/spack/spack/pull/46281 and https://github.com/spack/spack/pull/46062 Aug/Sep 2024. So only recently.
For CMake version < 3.30, keep using the boost module.
Test this please
Test this please
Thanks Ye!
Test this please
Proposed changes
Boost 1.70 was release in 2019.
Instead of the CMake shipped module file, upstream Boost's BoostConfig.cmake package configuration file will be used. This change requires installing boost properly but we only need the "headers" library. Untaring a boost archive won't work.
Installation of boost headers is very simple and quick
QMCPACK CMake takes
-DBOOST_ROOT=<location of your installation>
as usual.What type(s) of changes does this code introduce?
Does this introduce a breaking change?
What systems has this change been tested on?
laptop
Checklist