Test Visual Studio 2026 and update dependencies

[garethsb]

Move the primary Windows matrix to VS 2026 while retaining VS 2022 coverage, and update CMake and Conan dependencies to current supported releases.

[garethsb]

@lo-simon, @jonathan-r-thorpe, @aholzinger ... so I think there's an approach here to support VS 2026 and update deps (if we're happy with Boost 1.86.0) ... thoughts?

[aholzinger]

@garethsb Boost 1.86 does only help for current VS 2022 due to BoostDetectToolset.cmake:

if((MSVC_VERSION GREATER 1929) AND (MSVC_VERSION LESS 1950))

set(BOOST_DETECTED_TOOLSET "vc143")

In Boost 1.85 it does still look like this (1940 is too small for current VS 2022):

if((MSVC_VERSION GREATER 1929) AND (MSVC_VERSION LESS 1940))

set(BOOST_DETECTED_TOOLSET "vc143")

Regarding VS 2026, please note that there is no "vc145" in the above.

VS 2026 is supported only since Boost 1.91:

if((MSVC_VERSION GREATER 1949) AND (MSVC_VERSION LESS 1960))

set(BOOST_DETECTED_TOOLSET "vc145")

elseif((MSVC_VERSION GREATER 1929) AND (MSVC_VERSION LESS 1950))

set(BOOST_DETECTED_TOOLSET "vc143")

[garethsb]

VS 2026 is supported only since Boost 1.91

Hm, seems to be building and passing tests here though? What am I missing?

[aholzinger]

@garethsb It builds, but doesn't specialize for the toolset and emits this message (always BoostDetectToolset.cmake):

message(STATUS "Boost toolset is unknown (compiler ${CMAKE_CXX_COMPILER_ID} ${CMAKE_CXX_COMPILER_VERSION})")

[garethsb]

I don't think that affects correctness, does it? NmosCppDependencies.cmake relies on BOOST_ALL_NO_LIB so MSVC auto-link is off, the libraries are linked via the Boost:: targets, so having the toolset identifier in the library names is irrelevant?

Moving all of nmos-cpp, cpprestsdk and websocketpp past Boost 1.86.0 would be a bit of a headache? (Not the code changes, but using forked repos and getting those approved into Conan Center recipes, for example.)

[aholzinger]

Well, I'm not a Boost build expert, but I wouldn't use Boost with an unsupported toolset in a system critical application (without prior having checked all the inplications, ergo becoming a Boost build expert). For the time being I can live with VS 2022.

So for the moment I suggest to stick with Boost 1.86 (meaning not officially support VS 2026), but for the long term (Boost 1.86 is already two years old) the cpprestsdk issue has to be resolved anyhow, which is the way bigger issue. If a replacement is found I guess the changes in nmos-cpp regarding updated Boost Asio in newer Boost versions will be the smalles part.

[garethsb]

for the long term (Boost 1.86 is already two years old) the cpprestsdk issue has to be resolved anyhow, which is the way bigger issue. If a replacement is found I guess the changes in nmos-cpp regarding updated Boost Asio in newer Boost versions will be the smalles part.

True... That's #187.

Our (@lo-simon, @jonathan-r-thorpe) feeling until recently has been that we would maintain a feature-frozen fork of cpprestsdk if that became necessary, because we don't need new features for nmos-cpp, just platform/build/security updates. However, with 🤖 support it might now be practical to switch nmos-cpp to other async-task, JSON and HTTP/WebSocket libraries, though I suspect not without a lot of pain for application developers who have directly integrated nmos-cpp (rather than using one of the API wrappers like NVIDIA/nvnmos's C API or gRPC daemon or GStreamer plugin).

[aholzinger]

Well with Mythos you can probably fix the biggest part of any still unknown issues in cpprestsdk :-)

I was able to build nmos-cpp (without Conan) on a freshly installed Ubuntu based 26.04 LTS due to the fact that there was still Boost 1.83 available in the Ubuntu 26.04 repos. Once Boost 1.83 isn't in available anymore in the next LTS it will be less easy. At least then it would be nice to have nmos-cpp2 relying on current libs (at least Boost).

Obviously any changes in nmos-cpp will also hit myself then :-)

Thank you for considering Boost 1.86 for the moment.