On 17 March 2017 at 02:08, Tom Kent via Boost wrote:

On Thu, Mar 16, 2017 at 9:36 AM, Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

...

On 16 March 2017 at 13:09, Rene Rivera via Boost wrote:

...

After help from various sources to get the VS2017 building working the latest master snapshot should at least try and build with VS2017. Assuming nothing horrible shows up today we will release the first beta tonight. Hence, please smoke test the latest master snapshot found at:

https://dl.bintray.com/boostorg/master/

Thanks for the snapshot.

I did quick building subset of libraries using VS2017, with ZLIB_SOURCE and BZIP2_SOURCE defined. The build was successful. I did not run any tests though. Brief configuration log copied below.

Kudos to Tom Kent for recent patches towards VS2017 support.

Minor issue: - I run build inside "x64 Native Tools Command Prompt for VS 2017" - That is, using native 64-bit CL.EXE and targetting 64-bit platform. - In config.log, I see b2_msvc_14.10.25017_vcvarsx86_amd64_.cmd - In processes, I see b2 runs CL.EXE 32-bit cross-compiuler targetting 64-bit Would it be possible to run CL.exe 64-bit binary? Given I'm in the VS2017 command prompt configured with native 64-bit toolset...

I think this comes from build/src/tools/msvc.jam:1055. I'm not sure what to do about it though. I guess we need to look at the env variables: PROCESSOR_ARCHITECTURE, Platform, and PreferredToolArchitecture.

PreferredToolArchitecture as the hint would also be consistent with MSBuild. I've tried to force b2 to use 64-bit binary of cl.exe. I added this to project-config.jam using msvc : 14.10 : "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Professional\\VC\\Tools\\MSVC\\14.10.25017\\bin\\HostX64\\x64\\cl.exe" ; But then, it looks like failing to recognise the toolset: b2 toolset=msvc-14.10 F:/boost/tools/build/src/tools\msvc.jam:1103: in configure-really *** argument error * rule generate-setup-cmd ( version : command : parent : options * : cpu : global-setup ? : default-global-setup-options : default-setup ) * called with: ( 14.10.25017 14.10.25017 : C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64 : C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.10.25017\bin\HostX64 : <command>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.10.25017\bin\HostX86\x86\cl.exe <command>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\cl.exe : i386 : : x86 : vcvars32.bat ) * extra argument 14.10.25017 F:/boost/tools/build/src/tools\msvc.jam:811:see definition of rule 'generate-setup-cmd' being called F:/boost/tools/build/src/tools\msvc.jam:201: in configure F:/boost/tools/build/src/tools\msvc.jam:153: in msvc.init F:/boost/tools/build/src/build\toolset.jam:43: in toolset.using F:/boost/tools/build/src/build\project.jam:1052: in using project-config.jam:6: in modules.load F:/boost/tools/build/src\build-system.jam:249: in load-config F:/boost/tools/build/src\build-system.jam:412: in load-configuration-files F:/boost/tools/build/src\build-system.jam:524: in load F:\boost\tools\build\src/kernel\modules.jam:295: in import F:\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build F:\boost\boost-build.jam:17: in module scope F:\boost> Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

On Thu, Mar 16, 2017 at 4:00 PM, Tom Kent via Boost wrote:

On Thu, Mar 16, 2017 at 7:09 AM, Rene Rivera via Boost < boost@lists.boost.org> wrote:

...

After help from various sources to get the VS2017 building working the latest master snapshot should at least try and build with VS2017. Assuming nothing horrible shows up today we will release the first beta tonight. Hence, please smoke test the latest master snapshot found at:

https://dl.bintray.com/boostorg/master/

VS2017 is not yet working with master. When building the libraries it builds in the format "libboost_thread-vc1410-mt-1_64.lib", however the code in config/auto_link.hpp still has a vc150 in it, meaning any time you try to link a library you will get an error "libboost_thread-vc150-mt-1_64.lib not found".

I think that is easy enough to fix (and drastic enough) that we should hold the beta for it, but I defer to the release team.

Does master config have the changes for this? Does develop config? What are the changes? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Beman Dawes wrote: ...

...

...

VS2017 is not yet working with master. When building the libraries it builds in the format "libboost_thread-vc1410-mt-1_64.lib", ...

After a pull on both, C:\boost\develop\libs\config\include\boost\config\auto_link.hpp lines 171-172:

// vc14.1: # define BOOST_LIB_TOOLSET "vc141"

but C:\boost\master\libs\config\include\boost\config\auto_link.hpp lines 171-172:

// vc15: # define BOOST_LIB_TOOLSET "vc150"

IIUC, develop is correct, while master is out-of-date.

Looks like neither is correct; should be "vc1410".

On 17/03/2017 12:59, Tom Kent via Boost wrote:

...

Looks like neither is correct; should be "vc1410".

I submitted a pull request against develop to change to this, which matches the library output.

I asked this in another thread (I don't have a VS2017 install locally to check): what does $(PlatformToolsetVersion) in VS2017 C++ projects evaluate to? Because if that number is different than what Boost is putting in the filenames, it's going to cause integration pain to someone.

On 17/03/2017 13:47, Tom Kent via Boost wrote:

On Thu, Mar 16, 2017 at 7:36 PM, Gavin Lambert via Boost < boost@lists.boost.org> wrote:

...

On 17/03/2017 12:59, Tom Kent via Boost wrote:

...

Looks like neither is correct; should be "vc1410".

...

I submitted a pull request against develop to change to this, which matches the library output.

I asked this in another thread (I don't have a VS2017 install locally to check): what does $(PlatformToolsetVersion) in VS2017 C++ projects evaluate to?

Because if that number is different than what Boost is putting in the filenames, it's going to cause integration pain to someone.

$(PlatformToolsetVersion) is "141".

So then shouldn't b2 and Config be using "*-vc141-*"?

On Thu, Mar 16, 2017 at 7:47 PM, Tom Kent via Boost wrote:

On Thu, Mar 16, 2017 at 7:36 PM, Gavin Lambert via Boost < boost@lists.boost.org> wrote:

...

On 17/03/2017 12:59, Tom Kent via Boost wrote:

...

Looks like neither is correct; should be "vc1410".

...

I submitted a pull request against develop to change to this, which matches the library output.

I asked this in another thread (I don't have a VS2017 install locally to check): what does $(PlatformToolsetVersion) in VS2017 C++ projects evaluate to?

Because if that number is different than what Boost is putting in the filenames, it's going to cause integration pain to someone.

$(PlatformToolsetVersion) is "141".

Personally I would prefer 14.10 (aka 1410) because of purely selfish reasons. As it would mean Boost Predef already says that "14.10" is the version. But otherwise I don't care what version number it is. I'm beyond exhausted from dealing with VS version numbers. Which means.. 1. For the beta the version is "14.10", aka "1410". 2. And we'll apply the Boost Config patch accordingly. 3. After beta everyone can fight over what the "real" version number should be. 4. Apply changes after enough people agree. And if that's fast enough.. We can do another beta. Other we just wait for the release to have the change. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

...

Personally I would prefer 14.10 (aka 1410) because of purely selfish reasons. As it would mean Boost Predef already says that "14.10" is the version. But otherwise I don't care what version number it is. I'm beyond exhausted from dealing with VS version numbers. Which means..

1. For the beta the version is "14.10", aka "1410". 2. And we'll apply the Boost Config patch accordingly. 3. After beta everyone can fight over what the "real" version number should be. 4. Apply changes after enough people agree. And if that's fast enough.. We can do another beta. Other we just wait for the release to have the change. Where is 14.10 coming from? In the IDE and vcxproj files I only see 141.

Nod. I asked about this on the PR and got no reply, so let's try again here... We have history here - of using 3 figure version names, that includes VC7.1 which had the "71" suffix, IMO the trailing zero is at best superfluous, and at worst confusing. We should be consistent both with what we've done before, and with what MSVC reports. There is another issue with Boost.Build: * Open up a Visual studio 2017 command prompt, and bootstrap, then: * ./b2 toolset=msvc-14.10 builds libraries with the "1410" suffix, but: * ./b2 toolset=msvc-14.1 also seems to work and builds libraries with a "141" suffix. That shouldn't happen! Best, John. --- This email has been checked for viruses by AVG. http://www.avg.com

On Fri, Mar 17, 2017 at 5:31 AM, Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

On 17 March 2017 at 10:00, John Maddock via Boost wrote:

...

...

...

Personally I would prefer 14.10 (aka 1410) because of purely selfish reasons. As it would mean Boost Predef already says that "14.10" is the version. But otherwise I don't care what version number it is. I'm

beyond

...

...

...

exhausted from dealing with VS version numbers. Which means..

1. For the beta the version is "14.10", aka "1410". 2. And we'll apply the Boost Config patch accordingly. 3. After beta everyone can fight over what the "real" version number should be. 4. Apply changes after enough people agree. And if that's fast enough.. We can do another beta. Other we just wait for the release to have the change.

Where is 14.10 coming from? In the IDE and vcxproj files I only see 141.

Nod.

I asked about this on the PR and got no reply, so let's try again here...

We have history here - of using 3 figure version names, that includes VC7.1 which had the "71" suffix, IMO the trailing zero is at best superfluous, and at worst confusing. We should be consistent both with what we've done before, and with what MSVC reports.

Speaking of consistency, perhaps these two could be unified instead of adding up to the forest of names [1]

bootstrap.bat vc1410 b2 toolset=msvc-14.10

I'm not opposed to that, but those have historically been different. bootstrap.bat vc14 b2 toolset=msvc-14.0 Tom

On Fri, Mar 17, 2017 at 7:29 AM, Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

On 17 March 2017 at 09:10, Olaf van der Spek via Boost wrote:

...

On Fri, Mar 17, 2017 at 3:05 AM, Rene Rivera via Boost wrote:

...

...

$(PlatformToolsetVersion) is "141".

Personally I would prefer 14.10 (aka 1410) because of purely selfish reasons. As it would mean Boost Predef already says that "14.10" is the version. But otherwise I don't care what version number it is. I'm beyond exhausted from dealing with VS version numbers. Which means..

1. For the beta the version is "14.10", aka "1410". 2. And we'll apply the Boost Config patch accordingly. 3. After beta everyone can fight over what the "real" version number should be. 4. Apply changes after enough people agree. And if that's fast enough.. We can do another beta. Other we just wait for the release to have the change.

Where is 14.10 coming from?

NMAKE build utility, perhaps?

VS2017 is shipped with NMAKE.EXE /? Microsoft (R) Program Maintenance Utility Version 14.10.25017.0

I went through VS2017 and VS2015 to compare the macros that are available, here's what I found: Visual Studio 2017 Enterprise Default C++ Console Application project, Debug, x86 Default Platform Toolset - Project -> Properties -> Configuration Properties -> General -> Platform Toolset: Visual Studio 2017 (v141) Macros - Project -> Properties -> Configuration Properties -> C++ -> Additional Include Directories -> Edit -> Macros $(DefaultPlatformToolset) v141 $(PlatformToolset) v141 $(PlatformToolsetVersion) 141 $(Platform) Win32 $(PlatformArchitecture) 32 $(PlatformTarget) x86 $(TargetPlatformVersion) 10.0.14393.0 $(VCToolsVersion) 14.10.25017 $(VCToolArchitecture) Native32Bit $(MSBuildToolsVersion) 15.0 $(VCProjectVersion) 15.0 $(VisualStudioVersion) 15.0 Visaul Studio 2015 Enterprise Default C++ Console Application project, Debug, x86 Default Platform Toolset - Project -> Properties -> Configuration Properties -> General -> Platform Toolset: Visual Studio 2015 (v140) Macros - Project -> Properties -> Configuration Properties -> C++ -> Additional Include Directories -> Edit -> Macros $(DefaultPlatformToolset) v140 $(PlatformToolset) v140 $(PlatformToolsetVersion) 140 $(Platform) Win32 $(PlatformArchitecture) 32 $(PlatformTarget) x86 $(TargetPlatformVersion) 8.1 $(VCToolsVersion) N/A $(VCToolArchitecture) Native32Bit $(MSBuildToolsVersion) 14.0 $(VCProjectVersion) N/A $(VisualStudioVersion) 14.0 My (semi-)personal dog in the fight: For the binary builds that we've put on sourceforge, the libraries are organized in directories based on the b2 command that was used to build them. This b2 toolset=msvc-14.0 address-model=32 would make boost_1_XX_0/lib32-msvc-14.0/. This could then be added to Visual Studio's link path (across multiple project files for different compilers/architectures) with boost_1_XX_0/lib$( PlatformArchitecture)-msvc-$(VisualStudioVersion)/. Then the libraries in that directory were named with libboost_thread_vc140-X-1_XX.lib, which matched the output from the config/auto_link.hpp pragma, so the library names were automatically included. Short of making our toolset= set to the visual studio version instead of any c++ toolset, this isn't going to work anymore. Thanks MS! :-( Historically, this version change has never happened before. There *was* another .1 release Visual Studio .NET was 7.0 and had toolset vc70, Visual Studio .NET 2003 was 7.1 and had toolset vc71. With this .1 release, Microsoft at least kept the C++ version and greater visual studio version in lockstep, the current VS2017 situation is different.

From all the talk I've heard from MS about this being a big update, C++14, C++17, blah, blah, blah, I'm surprised they went and called it a minor version. It isn't minor enough that VS2015 programs can link against it, and if they wanted to indicate that VS2017 programs could link against VS2015 libs, they could have just said "it is now backwards compatible".

So frustrating.

Olaf van der Spek wrote:

On Sat, Mar 18, 2017 at 4:06 AM, Tom Kent via Boost wrote:

...

My (semi-)personal dog in the fight: For the binary builds that we've put on sourceforge, the libraries are organized in directories based on the b2 command that was used to build them. This b2 toolset=msvc-14.0 address-model=32 would make boost_1_XX_0/lib32-msvc-14.0/. This could then be added to Visual Studio's link path (across multiple project files for different compilers/architectures) with boost_1_XX_0/lib$(PlatformArchitecture)-msvc-$(VisualStudioVersion)/.

...

With one VS version supporting multiple toolsets you can't use the VS version anyway can you?

That's a good point. If I use, say, VS 2015 with the v120 toolset, I need to link to the vc120 libraries, not to the vc140 ones. So it seems that boost_1_XX_0/lib$(PlatformArchitecture)-vc$(PlatformToolsetVersion)/ is better.

Tom Kent wrote:

On Sat, Mar 18, 2017 at 7:41 AM, Peter Dimov via Boost wrote:

...

Olaf van der Spek wrote:

...

With one VS version supporting multiple toolsets you can't use the VS version anyway can you?

That's a good point. If I use, say, VS 2015 with the v120 toolset, I need to link to the vc120 libraries, not to the vc140 ones. So it seems that boost_1_XX_0/lib$(PlatformArchitecture)-vc$(PlatformToolsetVersion)/ is better.

I agree that this matches better with the way MS has evolved the platform, so does that mean that we should change boost build to match e.g. b2 toolset=vc-141?

That's not really something we should be doing at this particular point in time. msvc-14.1 is good enough for me.

On 18 March 2017 at 13:23, Mateusz Loskot wrote:

On 18 March 2017 at 04:06, Tom Kent via Boost wrote:

...

On Fri, Mar 17, 2017 at 7:29 AM, Mateusz Loskot via Boost wrote:

...

On 17 March 2017 at 09:10, Olaf van der Spek via Boost wrote:

...

Where is 14.10 coming from?

NMAKE build utility, perhaps?

VS2017 is shipped with NMAKE.EXE /? Microsoft (R) Program Maintenance Utility Version 14.10.25017.0

I went through VS2017 and VS2015 to compare the macros that are available, here's what I found:

$(PlatformToolsetVersion) 141 $(VCToolsVersion) 14.10.25017 $(VisualStudioVersion) 15.0 [...] $(PlatformToolsetVersion) 140 $(VCToolsVersion) N/A $(VisualStudioVersion) 14.0

To those above, adding versions from Visual Studio 2012, for example:

$(PlatformToolsetVersion) 110 $(VCToolsVersion) N/A $(VisualStudioVersion) 11.0

Now, we can not rely on: $(VCToolsVersion) - it is not defined for every VS toolset $(VisualStudioVersion) - from 15.0 or above, it no longer maps 1:1 with $(PlatformToolsetVersion)

AFAIS, BOOST_LIB_TOOLSET is based on "vc" + $(PlatformToolsetVersion)

# define BOOST_LIB_TOOLSET "vc110" # define BOOST_LIB_TOOLSET "vc140"

Then, for Visual Studio 2017 case, the macro should resolve to

# define BOOST_LIB_TOOLSET "vc140" // VS2017 + $(PlatformToolsetVersion) 140 # define BOOST_LIB_TOOLSET "vc141" // VS2017 + $(PlatformToolsetVersion) 141

Obviously, case of VS2015 (which always builds with v140), would be the same as VS2017 + $(PlatformToolsetVersion) # define BOOST_LIB_TOOLSET "vc140" // VS2015 + $(PlatformToolsetVersion) 140 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

On 18 Mar 2017 14:02, "Peter Dimov via Boost" wrote: Mateusz Loskot wrote: Obviously, case of VS2015 (which always builds with v140),

No, VS 2015 can build with v140, v120, v110, v100, v90, as long as you have the earlier versions installed. (VS 2017 can build with v140 even if you don't have VS 2015 installed.) I understood VS2017 is first version with multi-toolset support. Regards, Mateusz

On 03/17/17 05:05, Rene Rivera via Boost wrote:

On Thu, Mar 16, 2017 at 7:47 PM, Tom Kent via Boost wrote:

...

$(PlatformToolsetVersion) is "141".

Personally I would prefer 14.10 (aka 1410) because of purely selfish reasons. As it would mean Boost Predef already says that "14.10" is the version. But otherwise I don't care what version number it is. I'm beyond exhausted from dealing with VS version numbers. Which means..

1. For the beta the version is "14.10", aka "1410". 2. And we'll apply the Boost Config patch accordingly. 3. After beta everyone can fight over what the "real" version number should be. 4. Apply changes after enough people agree. And if that's fast enough.. We can do another beta. Other we just wait for the release to have the change.

In the (not sure how likely) case Microsoft releases 10 minor releases with the major version number 14 we'll be in an awkward position if we name the current VS release 14.10 - we'll have another release that is supposed to be 14.10. I think, 141 tag makes more sense, and also is more useful given that it matches PlatformToolsetVersion env. variable.

Rene Rivera wrote:

3. After beta everyone can fight over what the "real" version number should be.

msvc-14.1 is obviously correct. For one thing, 141 matches $(PlatformToolsetVersion); for another, _MSC_VER 1310 is msvc-7.1, not msvc-7.10. Plus, msvc-14.1 is the first thing I tried before learning that it should be .10, then I tried it again by mistake the following day even though I already knew about the .10.