Support Visual Studio 2026

@vattila In order to build the trunk with the new Visual Studio 2026, the toolset for the MSBuild projects must be updated to v145. But that will make them no longer be able to be built with VS2022.

Should we go forward and make trunk buildable with only the latest release of VS, or should we try for at least some period to support both 2022 and 2026 until people migrate to the latest?

@jogybl wrote:

In order to build the trunk with the new Visual Studio 2026, the toolset for the MSBuild projects must be updated to v145. [...] I found out how to parametrize the toolset setting

I was about to suggest parameterisation. Good to see you've already figured it out and implemented it!

Should we go forward and make trunk buildable with only the latest release of VS [...]?

I've not yet gotten around to upgrading to 2026. Keeping the 2022 support for a little transition period would be good, until we've all upgraded and any issues have been worked out. But in my view we should eventually move to only support the latest compiler versions on the trunk, for sake of simplicity and progress.

Going forward, I'm not yet sure how to best deal with the decoupling of VS IDE version and MSVC toolset version, now that their release cycles will be decoupled. However, this is mostly a documentation issue, I guess. Apart from OWLMaker, the code and build scripts only deal with the MSVC compiler and toolset versions.

@jogybl has added support on branches/6.36 [r8557], branches/644 [r8559], branches/7 [r8560] and trunk [r8561], as well as in OWLMaker [r8562].

@jogybl,

It is unnecessary to define both compiler tags "v1950" and "v145" for VS 2026. The latter should be used throughout. Two tags were needed for VS 2022 only because "v1930" was already established when I switched to use the platform toolset ("v143") as the compiler tag on the trunk.

Likewise, there is no need for two toolsets in OWLMaker to represent VS 2026. A single one will do; calling NMake or MSBuild as necessary based on the OWLNext version. The need for two toolsets for VS 2022 was only for convenience during development of the MSBuild support. It was useful to have both the NMake and MSBuild versions side by side, when the MSBuild version wasn't fully baked.

Revision [r8573] makes these simplifications and also bumps the trunk version to 8.0.6 to indicate new compiler support.

Pages [OWLNext_naming_convention], [Supported_Compilers] and [OWLNext_Stable_Releases] have been updated.

Edit: A regression (missing support for dynamic linking in OWLNext 7 and earlier) was fixed in revision [r8574]. Another regression (due to reliance on non-standard behaviour in regular expressions) was fixed in [r8575].