On Mon, Mar 13, 2017 at 10:58 PM, Stephan T. Lavavej via Boost wrote:

...

As I said before, for my opinion, I think we should move to msvc-15.0 for the toolset, as that will be *less* confusion for the end-users.

I disagree - 15 is the IDE's version number. The IDE can host multiple toolsets (already it can install v140 and v141; expect more in the future).

In the past IDE and toolset version numbers were equal weren't they?

Another approach would be to give up on the 14.x version numbers entirely (admittedly it is confusing to have the v141 toolset linking against msvcp140.dll for bincompat). Instead, use _MSC_VER as the toolset identifier - this is 1900 for VS 2015 (RTM/Updates) and 1910 for VS 2017 RTM, and will increase in a fairly predictable, monotonic way in the future.

Can't MS use a single version number for the compiler *and* the toolset? -- Olaf

On 14 March 2017 at 22:26, Stephan T. Lavavej via Boost wrote:

[Olaf van der Spek]

...

Can't MS use a single version number for the compiler *and* the toolset?

The compiler is part of the toolset (which includes the linker and the libraries). The IDE is distinct from the toolset.

At the moment, the compiler and the libraries march in lockstep - you can't use an older compiler with newer libraries (that will never work, ever) and we don't support using a newer compiler with older libraries. The toolset is versioned (according to the IDE) as v141 while the compiler is versioned at 19.1, but we consider them to be the same thing, really.

Digression: After day spent on updating fairly large build configuration to VS2017, what a dance of versions: MSBuild: PlatformToolset=v141 Boost: bootstrap.bat vc1410 Boost: b2 toolset=msvc-14.10 IncrediBuild: BuildConsole.exe /vsversion="vc15" (notice, "vs" in switch vs "vc" in value) CMake: Visual Studio 15 2017 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

I submitted a patch to CMake to treat 19.10 as '-vc150' in FindBoost.CMake months ago, see: https://gitlab.kitware.com/cmake/cmake/merge_requests/314 Now I think additional patch might be required due to recent change in Boost.build. On Fri, Mar 17, 2017 at 6:09 AM, Mateusz Loskot via Boost wrote:

On 14 March 2017 at 22:26, Stephan T. Lavavej via Boost wrote:

...

[Olaf van der Spek]

...

Can't MS use a single version number for the compiler *and* the toolset?

The compiler is part of the toolset (which includes the linker and the libraries). The IDE is distinct from the toolset.

At the moment, the compiler and the libraries march in lockstep - you can't use an older compiler with newer libraries (that will never work, ever) and we don't support using a newer compiler with older libraries. The toolset is versioned (according to the IDE) as v141 while the compiler is versioned at 19.1, but we consider them to be the same thing, really.

Digression: After day spent on updating fairly large build configuration to VS2017, what a dance of versions:

MSBuild: PlatformToolset=v141 Boost: bootstrap.bat vc1410 Boost: b2 toolset=msvc-14.10 IncrediBuild: BuildConsole.exe /vsversion="vc15" (notice, "vs" in switch vs "vc" in value) CMake: Visual Studio 15 2017

Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Boost - Dev mailing list wrote

[Tom Kent]

...

As I said before, for my opinion, I think we should move to msvc-15.0 for the toolset, as that will be *less* confusion for the end-users.

I disagree - 15 is the IDE's version number. The IDE can host multiple toolsets (already it can install v140 and v141; expect more in the future).

Another approach would be to give up on the 14.x version numbers entirely (admittedly it is confusing to have the v141 toolset linking against msvcp140.dll for bincompat). Instead, use _MSC_VER as the toolset identifier - this is 1900 for VS 2015 (RTM/Updates) and 1910 for VS 2017 RTM, and will increase in a fairly predictable, monotonic way in the future.

BTW, I'm trying out the VS2017's Clang with Microsoft CodeGen and I'm quite surprised that both, CL.EXE and Clang.exe identify themselve as Microsoft Compiler, via _MSC_VER F:\>cat test.cpp #ifdef _MSC_VER #error CL with Clang.exe here #endif int main() { return 0; } F:\>cl /nologo test.cpp test.cpp test.cpp(2): fatal error C1189: #error: CL with Clang.exe here F:\>"c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\ClangC2\14.10.25903\bin\HostX86\clang.exe" test.cpp test.cpp:2:2: error: CL with Clang.exe here #error CL with Clang.exe here ^ 1 error generated. F:\> This table at [1] seems to confirm that too. Is that a temporary (alpha/beta state?). Hopefully. Versioning two different compilers under the same _MSC_VER is clearly going to add up to the overall confusion and toolset version fiasco. [1] Identifying your Platform and Toolset https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-with-microsoft-code... -- Regards, Mateusz Loskot ----- -- Mateusz Loskot, http://mateusz.loskot.net -- View this message in context: http://boost.2283326.n4.nabble.com/build-VC-2017-version-number-tp4692260p46... Sent from the Boost - Dev mailing list archive at Nabble.com.

Tom Kent wrote:

On the other hand, the "toolset" that microsoft sets the compilers to is "v141".

Yes, and we use msvc-14.10 instead of msvc-14.1, to make sure we don't match anything. Plus, using msvc-14.1 as the toolset fails with "cl not found" as if we don't support 2017 yet.

Rene Rivera wrote:

I seriously considered abandoning the current scheme and going with Beman's suggestion of 19.10 at one point.

19.10 is certainly unambiguous but the problem with it is that no normal person remembers which VC++ is which _MSC_VER. Although no normal person remembers that VC++ 2008 is msvc-9.0 either.