Re: [boost] Status of Visual Studio 2017 support

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