[release] 1.64.0 please test master snapshot..

older
[review process] candidate library...

Rene Rivera

16 Mar 2017 16 Mar '17

12:09 p.m.

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/ -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Show replies by date

Mateusz Loskot

16 Mar 16 Mar

2:36 p.m.

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... Regards, Mateusz ################################################### Building Boost.Build engine Bootstrapping is done. To build, run: .\b2 To adjust configuration, edit 'project-config.jam'. Further information: - Command line help: .\b2 --help - Getting started guide: http://boost.org/more/getting_started/windows.html - Boost.Build documentation: http://www.boost.org/build/doc/html/index.html Performing configuration checks - 32-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes Building the Boost C++ Libraries. - symlinks supported : no - junctions supported : yes - hardlinks supported : yes - has_icu builds : no Component configuration: - atomic : not building - chrono : building - container : not building - context : not building - coroutine : not building - coroutine2 : not building - date_time : building - exception : not building - fiber : not building - filesystem : building - graph : not building - graph_parallel : not building - iostreams : building - locale : not building - log : not building - math : not building - metaparse : not building - mpi : not building - program_options : building - python : not building - random : not building - regex : building - serialization : not building - signals : not building - system : building - test : building - thread : building - timer : not building - type_erasure : not building - wave : not building ################################################### -- Mateusz Loskot, http://mateusz.loskot.net

Tom Kent

17 Mar 17 Mar

1:08 a.m.

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. I did a quick check running all five command windows on two VMs, one running a 64-bit win2012R2 and one running a 32-bit win7. On 64-bit windows install C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Visual Studio 2017\Visual Studio Tools Developer Command Prompt for VS 2017 Runs: %comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\Tools\VsDevCmd.bat" Sets: PROCESSOR_ARCHITECTURE=AMD64 x64 Native Tools Command Prompt for VS 2017 Runs: %comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvars64.bat" Sets: Platform=x64 PROCESSOR_ARCHITECTURE=AMD64 x64_x86 Cross Tools Command Prompt for VS 2017 Runs: %comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvarsamd64_x86.bat" Sets: Platform=x86 PreferredToolArchitecture=x64 PROCESSOR_ARCHITECTURE=AMD64 x86 Native Tools Command Prompt for VS 2017 Runs: %comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvars32.bat" Sets: Platform=x86 PROCESSOR_ARCHITECTURE=AMD64 x86_x64 Cross Tools Command Prompt for VS 2017 Runs: %comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvarsx86_amd64.bat" Sets: Platform=x64 PROCESSOR_ARCHITECTURE=AMD64 On Windows 7 - 32 Bit Install C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Visual Studio 2017\Visual Studio Tools Developer Command Prompt for VS 2017 Runs: %comspec% /k "C:\Program Files\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat" Sets: PROCESSOR_ARCHITECTURE=x86 x64 Native Tools Command Prompt for VS 2017 (cl.exe doesn't run!) Runs: %comspec% /k "C:\Program Files\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat" Sets: Platform=x64 PROCESSOR_ARCHITECTURE=x86 x64_x86 Cross Tools Command Prompt for VS 2017 (cl.exe doesn't run!) Runs: %comspec% /k "C:\Program Files\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsamd64_x86.bat" Sets: Platform=x86 PreferredToolArchitecture=x64 PROCESSOR_ARCHITECTURE=x86 x86 Native Tools Command Prompt for VS 2017 Runs: %comspec% /k "C:\Program Files\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars32.bat" Sets: Platform=x86 PROCESSOR_ARCHITECTURE=x86 x86_x64 Cross Tools Command Prompt for VS 2017 Runs: %comspec% /k "C:\Program Files\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsx86_amd64.bat" Sets: Platform=x64 PROCESSOR_ARCHITECTURE=x86 The full output of the DOS "set" command for each shell is in this gist: https://gist.github.com/teeks99/627dce6f298ba02592643f03fe36a68b Tom

Mateusz Loskot

10:25 a.m.

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

Olaf van der Spek

16 Mar 16 Mar

2:37 p.m.

On Thu, Mar 16, 2017 at 1:09 PM, 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/

VS2017 / W7: ...found 37620 targets... The Boost C++ Libraries were successfully built! Awesome, thanks a lot! -- Olaf

Peter Dimov

7:57 p.m.

Rene Rivera 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/

Worked for me using "b2 -j 8 toolset=msvc-14.10". Appveyor is also fixed. Thanks very much to all responsible! I do have one issue with the new 14.10 toolset though, unrelated to the above snapshot. It's that I have, in user-config.jam, the following: import feature ; import toolset ; using msvc : 8.0 ; feature.subfeature toolset msvc : std : cxx14 cxxlatest : optional composite propagated ; feature.compose toolset-msvc:stdcxx14 : <cxxflags>/std:c++14 ; feature.compose toolset-msvc:stdcxxlatest : <cxxflags>/std:c++latest ; which allows me to use "toolset=msvc-cxxlatest-14.0". But it doesn't work with 14.10; I get: C:\Projects\boost-git\boost\libs\mp11>b2 -j 8 test toolset=msvc-cxxlatest-14.10 C:/Projects/boost-git/boost/tools/build/src/build\feature.jam:313: in implied-subfeature from module feature error: "14.10" is not a known subfeature value of <toolset>msvc C:/Projects/boost-git/boost/tools/build/src/build\feature.jam:500: in feature.validate-value-string from module feature C:/Projects/boost-git/boost/tools/build/src/build\property.jam:276: in validate1 from module property C:/Projects/boost-git/boost/tools/build/src/build\property.jam:302: in validatefrom module property C:/Projects/boost-git/boost/tools/build/src/build\property.jam:311: in property.validate-property-sets from module property C:/Projects/boost-git/boost/tools/build/src/build\toolset.jam:156: in toolset.flags from module toolset C:/Projects/boost-git/boost/tools/build/src/tools\common.jam:438: in common.handle-options from module common C:/Projects/boost-git/boost/tools/build/src/tools\msvc.jam:928: in configure-really from module msvc C:/Projects/boost-git/boost/tools/build/src/tools\msvc.jam:201: in configure from module msvc C:/Projects/boost-git/boost/tools/build/src/tools\msvc.jam:153: in msvc.init from module msvc C:/Projects/boost-git/boost/tools/build/src/build\toolset.jam:43: in toolset.using from module toolset C:/Projects/boost-git/boost/tools/build/src\build-system.jam:461: in process-explicit-toolset-requests from module build-system C:/Projects/boost-git/boost/tools/build/src\build-system.jam:527: in load from module build-system C:\Projects\boost-git\boost\tools\build\src/kernel\modules.jam:295: in import from module modules C:\Projects\boost-git\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build from module C:\Projects\boost-git\boost\boost-build.jam:17: in module scope from module There's probably a place that is missing 14.10 somewhere.

Tom Kent

9 p.m.

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. Tom

Rene Rivera

9:03 p.m.

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

9:53 p.m.

On Thu, Mar 16, 2017 at 5:03 PM, Rene Rivera via Boost < boost@lists.boost.org> wrote:

...

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?

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. So it looks like at the least develop for config needs to be merged into master for config. HTH, --Beman

Peter Dimov

9:59 p.m.

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".

Tom Kent

11:59 p.m.

On Thu, Mar 16, 2017 at 4:59 PM, Peter Dimov via Boost < boost@lists.boost.org> wrote:

...

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".

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

Gavin Lambert

17 Mar 17 Mar

12:36 a.m.

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.

Tom Kent

12:47 a.m.

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".

Gavin Lambert

1:10 a.m.

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

Marcel Raad

10:11 a.m.

Boost - Dev mailing list wrote

...

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@.boost

...

...
wrote:

...
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-*"?

+1, I would also expect it to match $(PlatformToolsetVersion). Apart from that, everything works for me except the 150/1410 mismatch for autolinking that has already been mentioned. Thanks for bringing VS2017 support to Boost 1.64 at the last minute to all involved! -- View this message in context: http://boost.2283326.n4.nabble.com/release-1-64-0-please-test-master-snapsho... Sent from the Boost - Dev mailing list archive at Nabble.com.

Rene Rivera

2:05 a.m.

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

Olaf van der Spek

8:10 a.m.

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? In the IDE and vcxproj files I only see 141. -- Olaf

John Maddock

9 a.m.

...

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

Mateusz Loskot

10:31 a.m.

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 [1] http://lists.boost.org/Archives/boost/2017/03/233387.php -- Mateusz Loskot, http://mateusz.loskot.net

Tom Kent

11:19 a.m.

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

Mateusz Loskot

12:29 p.m.

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 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Tom Kent

18 Mar 18 Mar

3:06 a.m.

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

6:49 a.m.

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)/. 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! :-(

With one VS version supporting multiple toolsets you can't use the VS version anyway can you? What is the problem when you use auto linking? The file names are a detail and AFAIK all output files are staged into a single directory. -- Olaf

Peter Dimov

12:41 p.m.

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

1:10 p.m.

On Sat, Mar 18, 2017 at 7:41 AM, Peter Dimov via Boost < boost@lists.boost.org> wrote:

...

Olaf van der Spek 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 >

On Sat, Mar 18, 2017 at 4:06 AM, Tom Kent via Boost < boost@lists.boost.org> wrote: 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$(PlatformArch itecture)-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.

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? If so, should we retroactively add support (along side existing syntax) to allow b2 toolset=vc-140, b2 toolset=vc-80? Tom

Peter Dimov

1:29 p.m.

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.

Mateusz Loskot

12:23 p.m.

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 and in future # define BOOST_LIB_TOOLSET "vcXYZ" // VS2017 + $(PlatformToolsetVersion) XYZ Quoting STL: "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." Boost toolset names should keep deriving directly from $(PlatformToolsetVersion) Unless, I'm missing something, am I? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Mateusz Loskot

12:53 p.m.

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

Peter Dimov

1:01 p.m.

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.) There are also v140_clang_c2, v120_xp, and so on, but the suffixes don't show up in $(PlatformToolsetVersion).

Mateusz Loskot

1:04 p.m.

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

Peter Dimov

1:27 p.m.

Mateusz Loskot wrote:

...

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

The first version with multi-toolset support is VS 2012, although the only two toolsets supported are v110 and v110_xp, which share the same version. VS 2013 supports v90 - v120. VS 2015 supports v90 - v140. Wait, no, VS 2010 supports v100 and v90. :-)

Andrey Semashev

17 Mar 17 Mar

11:24 a.m.

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

12:01 p.m.

On Fri, Mar 17, 2017 at 6:24 AM, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...

On 03/17/17 05:05, Rene Rivera via Boost wrote: 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.

Technically Microsoft doesn't say they released 14.1. They say they released 141, i.e. one hundred forty one. Which is based on some components that are 14.10 and a compiler that is 19.10. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Peter Dimov

12:19 p.m.

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.

Rene Rivera

2:48 a.m.

On Thu, Mar 16, 2017 at 6:59 PM, Tom Kent via Boost wrote:

...

On Thu, Mar 16, 2017 at 4:59 PM, Peter Dimov via Boost < boost@lists.boost.org> wrote:

...
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", ...

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

After a pull on both, 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".

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

I can't seem to cherry-pick it to master. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2812

Age (days ago)

2814

Last active (days ago)

List overview

Download

34 comments

10 participants

participants (10)

Andrey Semashev
Beman Dawes
Gavin Lambert
John Maddock
Marcel Raad
Mateusz Loskot
Olaf van der Spek
Peter Dimov
Rene Rivera
Tom Kent