Re: [boost] Status of Visual Studio 2017 support

Subject: Re: [boost] Status of Visual Studio 2017 support
From: Billy O'Neal (VC LIBS) (bion_at_[hidden])
Date: 2017-02-21 07:31:20

>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 <boost-bounces_at_[hidden]> on behalf of Tom Kent via Boost <boost_at_[hidden]>
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 <boost_at_[hidden]>
wrote:

> On 20 February 2017 at 16:33, Tom Kent via Boost <boost_at_[hidden]>
> 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).

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