On 02/14/17 16:36, Olaf van der Spek via Boost wrote:
On Tue, Feb 14, 2017 at 2:28 PM, Glen Fernandes via Boost
wrote: Could anyone clarify any of these points: - Does Boost.Build in Boost 1.63.0 officially support VS2017? - Is there any schedule to fully support VS2017 in Boost 1.64.0? - Or, is that left at discretion of maintainers of individual libraries and VS2017 support might be reached gradually over several releases instead of in a single shot?
Looking at the dates, that patch was in June 2016 when VS2017 was not released yet, and Boost 1.63 was released in December 2016 when VS2017 had still not released yet. Seems normal that VS2017 isn't one of the supported implementations yet.
I imagine once VS2017/VC15/14.1 releases, the next Boost release after that will aim to support it.
By then we'll probably also have working testers at: 1. http://www.boost.org/development/tests/master/developer/summary.html 2. http://www.boost.org/development/tests/develop/developer/summary.html
I see it happen organically (and generally quickly) once a new implementation is officially released.
RCs have been available for months and RTM/RTW will be March 7th.
I don't get why the plan seems to be to wait for the final release. Doesn't it just delay the work that has to be done? Does it make the work significantly easier?
Yes, it does, because the final release may be significantly different from the pre-released versions. It is not unheard of entire features being removed or modified in the final release. Personally, I think MSVC already consumes too much effort to support its new versions. For example, I don't see as much fuss about testing gcc or clang pre-releases - these get introduced silently to the test matrix, with apparently no required changes to Boost.Build or Boost.Config. (Well, the latter may need to be updated if a previously missing/broken feature is supported in the new compiler, but that is not a showstopper.)