On 14 February 2017 at 10:11, Olaf van der Spek wrote:

On Tue, Feb 14, 2017 at 10:01 AM, Mateusz Loskot via Boost wrote:

...

Could anyone clarify any of these points: - Does Boost.Build in Boost 1.63.0 officially support VS2017?

As far as I know Boost doesn't build at all with VS2017.

AFAICT, based on some attempts, I can confirm that too. However, the merged pull request I linked makes me a bit confused about the support, at least in Boost.Build. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

On 14 February 2017 at 13:48, degski via Boost wrote:

On 14 February 2017 at 03:23, Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

...

On 14 February 2017 at 10:11, Olaf van der Spek wrote:

...

On Tue, Feb 14, 2017 at 10:01 AM, Mateusz Loskot via Boost wrote:

...

Could anyone clarify any of these points: - Does Boost.Build in Boost 1.63.0 officially support VS2017?

As far as I know Boost doesn't build at all with VS2017.

AFAICT, based on some attempts, I can confirm that too. However, the merged pull request I linked makes me a bit confused about the support, at least in Boost.Build.

Afaik VS2017 will be named VC14.1. The PR is wrong.

I take it as the PR was submitted at the time VS "15" Preview was available. AFAIK, the numbers are currently set to: VS 2017 Version number 15.0 CL version number: 19.10 Platform toolset: v141 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

On 14 February 2017 at 13:43, Edward Diener via Boost wrote:

On 2/14/2017 4:01 AM, Mateusz Loskot via Boost wrote:

...

In the mid of 2016, PR "Add support for Visual Studio 15" [1] was merged into develop and eventually into master branch. Although the patch was released in Boost 1.63.0, the release notes [2] are silent about that update. That is about Boost.Build, which I assume is the first to be updated to support a new toolkit.

I haven't checked current commits history of individual libraries. Status of VS2017 support in individual libraries may be at different stages.

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?

Support for a new compiler/version in Boost usually means two things: support in Boost Build and support in Boost Config. So asking whether Boost supports a particular new compiler/version implementation really means asking if Boost Build and Boost Config support that compiler/version.

Right. And, since there has been activity regarding Visual Studio 2017 (initially referred by Microsoft to as Visual Studio "15") in both, Build [1] and Config [2], those questions are still valid: has the support been completed or is that work in progress? Why Boost 1.63.0 release notes are silent about [1]? [1] https://github.com/boostorg/build/pull/132 [2] https://github.com/boostorg/config/pull/110 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

On 14 February 2017 at 14:01, Rene Rivera via Boost wrote:

On Tue, Feb 14, 2017 at 3:01 AM, Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

...

In the mid of 2016, PR "Add support for Visual Studio 15" [1] was merged into develop and eventually into master branch. Although the patch was released in Boost 1.63.0, the release notes [2] are silent about that update.

We never officially support, and hence don't mention in release notes, support for unreleased toolsets. Even if we work toward supporting such pre-releases.

I get it, thanks Rene!

...

- 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?

Yes, and support for any toolset, even the really old ones, is always an incremental work in progress. See the results linked above.

Thanks for that one too. I've got it clarified now. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

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? It does mean people can't test the new compiler with Boost.. -- Olaf

On 2017-02-14 14:50, Andrey Semashev via Boost wrote:

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.

We are not taking about about preview versions from last summer, we are now at RC5, 3 weeks from the formal release. You might want to consider that VS2017 is already the default download at Microsoft's https://www.visualstudio.com/ And people start to wonder why Boost is so far behind... Bo Persson

snd specifically STL, use Boost as a test of their compiler early on. And once the tester that is running vc15 gets its configuration working again, from Microsoft breaking it. You'll see a greener and more accurate representation of what libraries work or not. And if you think that's insufficient. We are particularly interested in people contributing personal time and resources to test compilers. And right now running regression tests for that particular compiler would be very welcome. And hence from this thread I will assume that very shorty we will see at least two of you run regression tests.

I just got the configuration on that machine fixed over the weekend, and the first regression run (teeks99-02n) executed against it last night. Looking at the results, it is clear that there are still some serious bugs there, many results complain about not being able to find microsoft's compiler "cl". I'm planning to leave that runner in the list, it should be executed every couple days. Tom

On Tue, Feb 14, 2017 at 4:17 PM, Bo Persson via Boost wrote:

You might want to consider that VS2017 is already the default download at Microsoft's https://www.visualstudio.com/

It's not, though there's a 2017 RC button.. -- Olaf

[Andrey Semashev]

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.

Our process is that between Previews and RC, we enter "ask mode" (ask for permission to make changes), and between RC and RTM we enter "escrow mode", which is a very strict lockdown. The only bugs that are fixed in escrow mode are of the form "it's melting users' hard drives and the metal fumes are making people dizzy". VS 2017 is a little different than before (in that we've intentionally had 4 release candidates so far, although not prominently branded as such), but we're definitely locked down now. A useful heuristic is that when we've publicly announced the release date for RTM, as we recently did (March 7), the time for major changes is long past. The toolset (compiler/linker/libraries), which is what Boost is interested in, also locks down before the rest of the product, because we're at a low level in the stack. Throughout 10 years in Visual C++, I've taken several fixes through ask mode, but never through escrow mode that I can recall. We're focused on the next toolset update at the moment. For Boost, the policy I would recommend is: treat Previews as unsupported (major feature changes in them), but attempt to support RC builds when they appear. This will lead to better synchronization between Boost and VS releases. STL

On 2/14/2017 1:33 PM, Beman Dawes via Boost wrote:

On Tue, Feb 14, 2017 at 1:07 PM, Stephan T. Lavavej via Boost < boost@lists.boost.org> wrote:

...

[Andrey Semashev]

...

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.

Our process is that between Previews and RC, we enter "ask mode" (ask for permission to make changes), and between RC and RTM we enter "escrow mode", which is a very strict lockdown. The only bugs that are fixed in escrow mode are of the form "it's melting users' hard drives and the metal fumes are making people dizzy".

VS 2017 is a little different than before (in that we've intentionally had 4 release candidates so far, although not prominently branded as such), but we're definitely locked down now. A useful heuristic is that when we've publicly announced the release date for RTM, as we recently did (March 7), the time for major changes is long past.

The toolset (compiler/linker/libraries), which is what Boost is interested in, also locks down before the rest of the product, because we're at a low level in the stack. Throughout 10 years in Visual C++, I've taken several fixes through ask mode, but never through escrow mode that I can recall. We're focused on the next toolset update at the moment.

For Boost, the policy I would recommend is: treat Previews as unsupported (major feature changes in them), but attempt to support RC builds when they appear. This will lead to better synchronization between Boost and VS releases.

+1

Times of changed; Microsoft and other compiler vendors used to be very close lipped about what would actually be in a release. Nowadays the C++ community gets lots of notice and multiple release candidates well ahead of releases. There is much more openness, and lots of two-way conversations, both public and private. Times have changed.

The Visual Studio 2017 release is big deal - it means all major compilers now support virtually all C++11 and C++14 features, and Boost library maintainers can drop support for non-C++11 compilers in good conscience.

I do no think it is that easy. There are probably still some end-users not compiling in C++11 mode on up, and dropping support for non-C++11 compilers in the form of using C++11 on up features in code is going to leave those people behind. How about the more reasonable: if you are creating a new library use c++11 on up whereas if you are supporting an old library think about whether or not you want to lose end-users by using C++11 on up without checking Boost Config support for such features.

The sooner Boost Build and other aspects of boost support msvc 2017, the better, IMO.

Should I dare ask whether msvc 2017 has fixed its non-standard proprocessor so that it follows the C++ standard ? I think not, as I don't want to be disappointed by the answer.

--Beman

On Tue, Feb 14, 2017 at 12:07 PM, Stephan T. Lavavej via Boost < boost@lists.boost.org> wrote:

[Andrey Semashev]

...

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.

Our process is that between Previews and RC, we enter "ask mode" (ask for permission to make changes), and between RC and RTM we enter "escrow mode", which is a very strict lockdown. The only bugs that are fixed in escrow mode are of the form "it's melting users' hard drives and the metal fumes are making people dizzy".

Haha, lovely analogy.. Kinda subjective though. For example I would consider the state of finding the vs install location to be in the order of "making people dizzy". But that's just my opinion from having to deal with the fallout of making b2 work for it. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On Tue, Feb 14, 2017 at 4:29 PM, Andrew Pardoe via Boost < boost@lists.boost.org> wrote:

[Rene Rivera] For example I would consider the state of finding the vs install location to be in the order of "making people dizzy". But that's just my opinion from having to deal with the fallout of making b2 work for it.

If you're having trouble locating the install location, please reach out to me. There's a straightforward way to do it programmatically. More info can be found on this Reddit thread and the blog post referenced: https://www.reddit.com/r/cpp/comments/5t3881/visual_studio_ 2017_will_be_released_on_march_7/ddmowka/

We're coming out with a VC++ blog post and (I presume) a better code sample soon.

Yes! We need a way to do it without compiling any code. See the discussion in this (nasty) pull request: https://github.com/boostorg/build/pull/159 Tom

On 15/02/2017 11:29, Andrew Pardoe via Boost wrote:

If you're having trouble locating the install location, please reach out to me. There's a straightforward way to do it programmatically. More info can be found on this Reddit thread and the blog post referenced: https://www.reddit.com/r/cpp/comments/5t3881/visual_studio_2017_will_be_rele...

Maybe I'm just misreading something, but is that saying that the point of the changes is to allow multiple versions of VS2017 to be installed side-by-side? What's the point of doing that? I mean, I can understand multiple VS versions side-by-side (I currently have 2008, 2013, and 2015 installed, and use all three regularly) but I don't see the point of multiple of the same (even if at different update levels). The blog post talks about installing C++ support in one directory and Web support in a different one, or something like that, but again, what's the point? I can understand wanting to install only one or the other, but if you want both, they both should be installed in the same directory, as in previous versions. Having separate installed directories for each is just weird and inconvenient.

On Thu, Feb 16, 2017 at 4:31 AM, Andrew Pardoe via Boost wrote:

[Gavin] Maybe I'm just misreading something, but is that saying that the point of the changes is to allow multiple versions of VS2017 to be installed side-by-side? What's the point of doing that?

This is a feature that many developers have asked for. In addition to being able to have different versions of VS installed side-by-side, VS now uninstalls cleanly (except for "singletons", items like the .NET Framework or the Windows SDKs that get installed in one known location per machine.) Also, we no longer need a hacked-up C++ Build Tools SKU: it's supported by the installer. In fact, you can pretty much always install just what you need though possibly not to the desired granularity. You can have a machine with just C++ and no C# if you like.

Yes, each of these features were attainable without the other and you're welcome to question the value of any single one. But as the VS development cycle accelerates we hope the benefits of this work become more clear. If not, sorry to complicate your life unnecessarily : )

[Tom] Yes! We need a way to do it without compiling any code. See the discussion in this (nasty) pull request:

I've responded on the issue related to the PR. To summarize, you have three options. One is to pull down a pre-built binary from your repo. (I'm looking into whether we can't get this binary installed with MSVC to a known location, but no promises.) Another is to use PowerShell, but that has its own issues. The last is a piece of ugly command script that brute forces the problem. See the issue or read on for more.

[Rene] But I'm tired of thinking how to sold Microsoft problems. And instead invite you to solve the Boost Build problem in regards to VS15. Can you make this script https://github.com/boostorg/build/blob/develop/src/engine/build.bat correctly build b2.exe with vs15 portably without any outside requirements, other than VS15 is installed? And make it not fail for Windows 7 and onward at minimum.

We do have a lot of Microsoft problems, it's true. And sometimes we make new ones. Sorry for that, and thank you for pointing out when we do.

Here's an ugly and inefficient bit of command script that might work for your purposes:

for %%i in (a b c d e f g h i j k l m n o p q r s t u v w x y z) do for /F "tokens=*" %%j in ('dir /s /b %%i:\vcvars64.bat') do call "%%j" call where cl.exe && (echo success) || (echo cl.exe not found)

Ouch ;) Wouldn't it make sense to have one VS install, chosen by the user of course, be the default? -- Olaf

On 17/02/2017 04:03, Andrew Pardoe via Boost wrote:

Visual Studio used to install onto a developer's machine like a dump truck of bricks being unloaded. The VS team made some design choices to help make VS install lighterweight, less impactful, and uninstallable.

These are laudable goals, and this is what you said in your previous message that developers were actually asking for -- for example the ability to install only C# with nothing else, or only Web, or only Phone, or whatever.

As a side-effect of that design, it's also able to be installed side-by-side.

This, however, seems like a non-goal that only introduces problems without actually solving any. It's a classic example of a developer thinking "hey this is cool, we can do this now" without actually having a real business case for it, and in fact ending up being what nobody actually wants. (Somewhat like the SHOUTING MENUS, although in that case it's an artist rather than a programmer at fault.) So yes, have the lightweight componentised installer. But make it so that you can install C++ now, and then install Web *to the same place* later, and then uninstall C++ without uninstalling Web, all without having multiple install instances that confuse everyone. (Or if that's too hard, make it so that you have to uninstall everything and then can reinstall fewer components next time. People don't uninstall that often anyway.)

On Fri, Feb 17, 2017 at 3:37 AM, Olaf van der Spek via Boost wrote:

On Thu, Feb 16, 2017 at 4:03 PM, Andrew Pardoe via Boost wrote:

...

[Olaf] Wouldn't it make sense to have one VS install, chosen by the user of course, be the default?

...

The problem is in locating that one VS install.

On Linux one can just do g++ a.cpp, wouldn't it be nice if something similar could be done on Windows?

All kinds of command line tools need to do all kinds of tricks to find other tools it seems (on Windows).

In a (non-Boost) project with which I've helped, there's a script that does the following: 0. The user specifies desired VS version by setting an environment variable to (e.g.) "120" for VS 2013. 1. The script concatenates "VS" + version + "COMNTOOLS" to form an environment variable name. 2. In the directory indicated by that environment variable, it finds VCVarsQueryRegistry.bat. 3. It runs VCVarsQueryRegistry.bat in a child process that reports VCINSTALLDIR to the parent script. 4. Finally it runs %VCINSTALLDIR%\vcvarsall.bat, passing either x86 or x64 depending on the user. If that doesn't work with VS 2017, or for that matter with VS 2015, they'll need an algorithm that *does* work.

On 20 February 2017 at 04:25, Olaf van der Spek via Boost < boost@lists.boost.org> wrote:

Wouldn't it be much simpler if you let the user pick the right dev environment prompt from the start menu and have all stuff available without having to call extra scripts?

I fully agree. If one develops with VS20XX on Windows and one is unable to pick and start a dev environment, it then seems doubtfull that anyone has any use for a (generally) complex collection of libraries (and terse documentation) like Boost. degski

On 20 February 2017 at 16:33, Tom Kent via Boost wrote:

I strongly diagree with that. The primary use case for windows developers with visual studio is as a user of the headers and .lib/.dll files that come out of boost, inside their project files (configured with a gui to add include/library paths).

You seem to imply that the above is different for developers not on windows (other than the "gui" being bash and vim). Most users do not need boost build except for the

step where they need to create the compatible static/dynamic libraries that they will later use.

Isn't the above what everybody does with any library (build and link in ones' projects).

The issue here for most of them is that the current boost-build can't build libraries that are compatible with VS2017.

The libraries (any) built with VS2015 (VC14.0) will do equally well in this (VC14.1) case, while at the same time VS2017 has not been released yet. The current boost release pre-dates VS2017.

The command line usage to build the boost libraries from the ground up needs to be dead-simple...

It IS dead simple, the boost build documentation could be pointier though.

...so that it can be followed even by developers who don't know what an environmental variable is.

Are they required to know how to turn on their computer, or is this also outside requirements? degski

I'll be shocked in libraries built with msvc-14.0 are compatible with msvc-15.0 (toolset v141). For one, there are new C++14 features only in msvc-15.0, so they won't have been built in for libraries built with msvc-14.0. I think naming the toolset v141 was a big mistake as it seems to be about as close to v140 as v140 was to v120 (there was never a v130 toolset).

Even if you have a newer library that needs C++14 features and thus will only build with VS2017 / v141, it will be link compatible with older code built with VS2015 / v140. This is no different than how 2015 Updates were still v140 but delivered new C++ features. (I believe, but am not certain, the only reason the number was bumped at all was that people didn't like testing _MSC_FULL_VER to detect presence of features added in updates) ________________________________ From: Boost on behalf of Tom Kent via Boost Sent: Monday, February 20, 2017 6:47:05 PM To: Boost Developers List Cc: Tom Kent Subject: Re: [boost] Status of Visual Studio 2017 support On Mon, Feb 20, 2017 at 5:32 PM, degski via Boost wrote:

On 20 February 2017 at 16:33, Tom Kent via Boost wrote:

...

I strongly diagree with that. The primary use case for windows developers with visual studio is as a user of the headers and .lib/.dll files that come out of boost, inside their project files (configured with a gui to add include/library paths).

You seem to imply that the above is different for developers not on windows (other than the "gui" being bash and vim).

...

step where they need to create the compatible static/dynamic libraries

Most users do not need boost build except for the that

...

they will later use.

Isn't the above what everybody does with any library (build and link in ones' projects).

Visual studio has all the settings in the project file, so most developers don't have to set them themselves. I guess it is comparable to how a package manager will add libraries to a directory in the default library path on linux. The key here is that developers, even relatively decent ones, may not have a lot of the background that a typical linux user would have. Specifically, opening the command prompt and running a simple b2 command is a lot to ask for even some moderate level windows developers (sadly).

...

The issue here for most of them is that the current boost-build can't build libraries that are compatible with VS2017.

The libraries (any) built with VS2015 (VC14.0) will do equally well in this (VC14.1) case, while at the same time VS2017 has not been released yet. The current boost release pre-dates VS2017.

I'll be shocked in libraries built with msvc-14.0 are compatible with msvc-15.0 (toolset v141). For one, there are new C++14 features only in msvc-15.0, so they won't have been built in for libraries built with msvc-14.0. I think naming the toolset v141 was a big mistake as it seems to be about as close to v140 as v140 was to v120 (there was never a v130 toolset). Clearly this support isn't in 1.63, and isn't even in develop yet. Hopefully it will be available in time for the 1.64 release (April 12) however, as that is due out about a month after the msvc-15.0 release (March 7). I've got a test runner in the matrix that is setup with the current RC (teeks99-09n), but it isn't getting very far into the build because of boost-build config issues. Tom _______________________________________________ Unsubscribe & other changes: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.boost.org%2Fmailman%2Flistinfo.cgi%2Fboost&data=02%7C01%7Cbion%40microsoft.com%7Ca3dc7a44d2c94a48413808d45a03ff41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636232420595966950&sdata=napZUYnizaPo1YSx%2FRaBup98Ir9XUU4HzX3ZY8IRSi4%3D&reserved=0

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Bo Persson via Boost Sent: 21 February 2017 10:17 To: boost@lists.boost.org Cc: Bo Persson Subject: Re: [boost] Status of Visual Studio 2017 support

On 2017-02-21 03:47, Tom Kent via Boost wrote:

...

On Mon, Feb 20, 2017 at 5:32 PM, degski via Boost wrote:

...

On 20 February 2017 at 16:33, Tom Kent via Boost wrote:

...

I strongly diagree with that. The primary use case for windows developers with visual studio is as a user of the headers and .lib/.dll files that come out of boost, inside their project files (configured with a gui to add include/library paths).

You seem to imply that the above is different for developers not on windows (other than the "gui" being bash and vim).

...

...

step where they need to create the compatible static/dynamic libraries

Most users do not need boost build except for the that

...

they will later use.

Isn't the above what everybody does with any library (build and link in ones' projects).

Visual studio has all the settings in the project file, so most developers don't have to set them themselves. I guess it is comparable to how a package manager will add libraries to a directory in the default library path on linux. The key here is that developers, even relatively decent ones, may not have a lot of the background that a typical linux user would have. Specifically, opening the command prompt and running a simple b2 command is a lot to ask for even some moderate level windows developers (sadly).

Even if we know how to do it, we might not want to.

Usually on Windows you click on Setup.exe and get a list of options on what you can install. You can see what is available, and select the parts you want.

That is a lot easier, and more confortable, than reading some documentation to try to come up with an incantation like

b2 toolset=msvc-12.0,msvc-14.0

Some of us think that C:\> on a black background perhaps isn't the ultimate user experience.

So are you offering to build a GUI that will output the necessary command line after choosing from the myriad of options? Doesn't sound rocket-science for those that know about these things? GSoC task? Many years ago I would have liked this before I was forced to re-learn more about command lines that I wanted to (having imagined that command line were so last-millennial). Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

On 20 February 2017 at 20:47, Tom Kent via Boost wrote:

Specifically, opening the command prompt and running a simple b2 command is a lot to ask for even some moderate level windows developers (sadly).

Could you please back that up with information from a reliable source or stop talking out of your backside.

I'll be shocked in libraries built with msvc-14.0 are compatible with msvc-15.0 (toolset v141). For one, there are new C++14 features only in msvc-15.0, so they won't have been built in for libraries built with msvc-14.0. I think naming the toolset v141 was a big mistake as it seems to be about as close to v140 as v140 was to v120 (there was never a v130 toolset).

You saw what Billy O'Neal wrote: "It's an update". As to the availability of C++14 features (the ones not baked into a VS2015 boost build), I doubt that these features have a (measurable) impact to an extent that jumping up and down over the support by Boost of a not yet released version of VS is warranted. degski

On 21 February 2017 at 09:23, Rene Rivera via Boost wrote: First; We should strive to be a bit more civil in this community.

Indeed, we should. degski

On 14 February 2017 at 14: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. [...]

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?

It does mean people can't test the new compiler with Boost..

Olaf's reasoning is what made me wonder and start this thread. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net