libigl build fails on windows arm64 target architecture

Describe your issue

We found that libigl build fails on windows arm64 target architecture。

C:\gitP\libigl\libigl\build_arm64\_deps\boost-src\boost\multiprecision\cpp_int\intel_intrinsics.hpp(113,11): error C3861: '_addcarry_u32': identifier not found [C:\gitP\libigl\libigl\build_arm64\igl_copyleft_cgal.vcxproj]
C:\gitP\libigl\libigl\build_arm64\_deps\boost-src\boost\multiprecision\cpp_int\intel_intrinsics.hpp(118,11): error C3861: '_subborrow_u32': identifier not found [C:\gitP\libigl\libigl\build_arm64\igl_copyleft_cgal.vcxproj]

refer to https://github.com/microsoft/vcpkg/issues/17312. This problem has been fixed in boost 1.79. However, we found during setup that a dependency MPFR was built with boost 1.77, which caused this error.

-- Found MPFR: C:/gitP/libigl/libigl/build_arm64/_deps/mpfr-src/include  
-- Third-party: creating targets 'Boost::boost'...
CMake Warning (dev) at C:/Program Files/Microsoft Visual Studio/2022/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.28/Modules/FetchContent.cmake:1331 (message):
  The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy CMP0135 is
  not set.  The policy's OLD behavior will be used.  When using a URL
  download, the timestamps of extracted files should preferably be that of
  the time of extraction, otherwise code that depends on the extracted
  contents might not be rebuilt if the URL changes.  The OLD behavior
  preserves the timestamps from the archive instead, but this is usually not
  what you want.  Update your project to the NEW behavior or specify the
  DOWNLOAD_EXTRACT_TIMESTAMP option with a value of true to avoid this
  robustness issue.
Call Stack (most recent call first):
  build_arm64/_deps/boost-cmake-src/CMakeLists.txt:10 (FetchContent_Declare)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Fetching Boost
-- Fetching Boost - done
-- Boost found: 1.77.0 C:/gitP/libigl/libigl/build_arm64/_deps/boost-src

Then we tried to install the latest boost using vcpkg, but it was still 1.77 during setup. Why is this? How can we avoid this problem?
Setup.log
Build.log
vcpkg.log
Here are the logs for infomation.

Checklist

• I have read the bug report page
• CMake issue: I have tried with a fresh clone/empty build directory

Platform

• Windows
• macOS Intel
• macOS Arm (e.g., M1, M2)
• Linux

Start by reproducing the Windows ARM64 build in a fresh build directory and read Setup.log, Build.log, and vcpkg.log. Trace the dependency setup that fetches Boost 1.77 and builds MPFR, then verify which Boost version is selected. Done means the Windows ARM64 target configures and builds without the missing _addcarry_u32 and _subborrow_u32 errors.