Update to vcpkg-action@v6 and use vcpkg-binarycache

[johnwason]

Update to v6 of vcpkg-action. v6 optionally uses the new built-in GitHub caching for vcpkg to provide more accurate caching.

[Levi-Armstrong]

@johnwason Do you know why CI is failing?

[johnwason]

No I am not sure why it is failing.

[johnwason]

The error on windows-2022 is:

2024-03-08T06:21:55.5053089Z    Creating library ompl\tesseract_motion_planners_ompl.lib and object ompl\tesseract_motion_planners_ompl.exp
2024-03-08T06:21:55.5057406Z ompl.lib(PRM.cpp.obj) : error LNK2019: unresolved external symbol _Thrd_sleep_for referenced in function "void __cdecl std::this_thread::sleep_for<__int64,struct std::ratio<1,1000> >(class std::chrono::duration<__int64,struct std::ratio<1,1000> > const &)" (??$sleep_for@_JU?$ratio@$00$0DOI@@std@@@this_thread@std@@YAXAEBV?$duration@_JU?$ratio@$00$0DOI@@std@@@chrono@1@@Z)
2024-03-08T06:21:55.5061053Z ompl.lib(SPARS.cpp.obj) : error LNK2001: unresolved external symbol _Thrd_sleep_for
2024-03-08T06:21:55.5062667Z ompl.lib(PlannerTerminationCondition.cpp.obj) : error LNK2001: unresolved external symbol _Thrd_sleep_for
2024-03-08T06:22:06.8790957Z ompl.lib(Planner.cpp.obj) : error LNK2001: unresolved external symbol _Thrd_sleep_for

I have no idea why this is happening since _Thrd_sleep_for is part of the standard C++ library. There is only one version of Visual C++ installed so it shouldn't be a version mismatch.

@ooeygui do you have any advice on how to fix this error?

[ooeygui]

@johnwason Hey there,
This looks like a toolchain version difference between the ompl build and tesseract. I suspect the github binary cache is using a newer visual studio toolchain. Try removing that? Or migrate the toolchain for tesseract forward? (although that may have nasty implications of users of tesseract)

[johnwason]

I switched back to the old cache method and confirmed that ompl and other vcpkg were not cached. I still see the same error.

[ooeygui]

I see what's going on.
All Windows-2022 builds are failing, not just this change.

Ompl is built using mingw, but the rest of is built using visual studio. I'm trying to figure out why it is getting brought in.

-- Extracting source D:/a/tesseract_planning/tesseract_planning/vcpkg/downloads/ompl-ompl-1.5.1.tar.gz
-- Applying patch 0001_Export_targets.patch
-- Applying patch 0002_Fix_config.patch
-- Using source at D:/a/tesseract_planning/tesseract_planning/vcpkg/buildtrees/ompl/src/1.5.1-b7b5702eed.clean
-- Found external ninja('1.11.0').
-- Configuring x64-windows-release-rel
-- Building x64-windows-release-rel
-- Downloading https://mirror.msys2.org/mingw/mingw32/mingw-w64-i686-pkgconf-1~1.8.0-2-any.pkg.tar.zst;https://repo.msys2.org/mingw/mingw32/mingw-w64-i686-pkgconf-1~1.8.0-2-any.pkg.tar.zst;https://mirror.yandex.ru/mirrors/msys2/mingw/mingw32/mingw-w64-i686-pkgconf-1~1.8.0-2-any.pkg.tar.zst;https://mirrors.tuna.tsinghua.edu.cn/msys2/mingw/mingw32/mingw-w64-i686-pkgconf-1~1.8.0-2-any.pkg.tar.zst;https://mirrors.ustc.edu.cn/msys2/mingw/mingw32/mingw-w64-i686-pkgconf-1~1.8.0-2-any.pkg.tar.zst;https://mirror.selfnet.de/msys2/mingw/mingw32/mingw-w64-i686-pkgconf-1~1.8.0-2-any.pkg.tar.zst -> mingw-w64-i686-pkgconf-1~1.8.0-2-any.pkg.tar.zst...
-- Downloading https://mirror.msys2.org/msys/x86_64/msys2-runtime-3.4.6-1-x86_64.pkg.tar.zst;https://repo.msys2.org/msys/x86_64/msys2-runtime-3.4.6-1-x86_64.pkg.tar.zst;https://mirror.yandex.ru/mirrors/msys2/msys/x86_64/msys2-runtime-3.4.6-1-x86_64.pkg.tar.zst;https://mirrors.tuna.tsinghua.edu.cn/msys2/msys/x86_64/msys2-runtime-3.4.6-1-x86_64.pkg.tar.zst;https://mirrors.ustc.edu.cn/msys2/msys/x86_64/msys2-runtime-3.4.6-1-x86_64.pkg.tar.zst;https://mirror.selfnet.de/msys2/msys/x86_64/msys2-runtime-3.4.6-1-x86_64.pkg.tar.zst -> msys2-msys2-runtime-3.4.6-1-x86_64.pkg.tar.zst...

[johnwason]

Thanks @ooeygui!

@Levi-Armstrong I think we are good to merge this commit once the CI finishes and then open an issue about the windows-2022 build problem.

[johnwason]

See #446