[release] 1.64.0 please test master snapshot..

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [release] 1.64.0 please test master snapshot..

Boost - Dev mailing list
On Fri, Mar 17, 2017 at 5:31 AM, Mateusz Loskot via Boost <
[hidden email]> wrote:

> On 17 March 2017 at 10:00, John Maddock via Boost <[hidden email]>
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [release] 1.64.0 please test master snapshot..

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 03/17/17 05:05, Rene Rivera via Boost wrote:

> On Thu, Mar 16, 2017 at 7:47 PM, Tom Kent via Boost <[hidden email]>
> 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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [release] 1.64.0 please test master snapshot..

Boost - Dev mailing list
On Fri, Mar 17, 2017 at 6:24 AM, Andrey Semashev via Boost <
[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [release] 1.64.0 please test master snapshot..

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [release] 1.64.0 please test master snapshot..

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 17 March 2017 at 09:10, Olaf van der Spek via Boost
<[hidden email]> wrote:

> On Fri, Mar 17, 2017 at 3:05 AM, Rene Rivera via Boost
> <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [release] 1.64.0 please test master snapshot..

Boost - Dev mailing list
On Fri, Mar 17, 2017 at 7:29 AM, Mateusz Loskot via Boost <
[hidden email]> wrote:

> On 17 March 2017 at 09:10, Olaf van der Spek via Boost
> <[hidden email]> wrote:
> > On Fri, Mar 17, 2017 at 3:05 AM, Rene Rivera via Boost
> > <[hidden email]> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [release] 1.64.0 please test master snapshot..

Boost - Dev mailing list
On Sat, Mar 18, 2017 at 4:06 AM, Tom Kent via Boost
<[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [release] 1.64.0 please test master snapshot..

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 18 March 2017 at 04:06, Tom Kent via Boost <[hidden email]> wrote:

> On Fri, Mar 17, 2017 at 7:29 AM, Mateusz Loskot via Boost <[hidden email]> wrote:
>> On 17 March 2017 at 09:10, Olaf van der Spek via Boost<[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [release] 1.64.0 please test master snapshot..

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Olaf van der Spek wrote:

> On Sat, Mar 18, 2017 at 4:06 AM, Tom Kent via Boost
> <[hidden email]> 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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [release] 1.64.0 please test master snapshot..

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 18 March 2017 at 13:23, Mateusz Loskot <[hidden email]> wrote:

> On 18 March 2017 at 04:06, Tom Kent via Boost <[hidden email]> wrote:
>> On Fri, Mar 17, 2017 at 7:29 AM, Mateusz Loskot via Boost <[hidden email]> wrote:
>>> On 17 March 2017 at 09:10, Olaf van der Spek via Boost<[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [release] 1.64.0 please test master snapshot..

Boost - Dev mailing list
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).


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [release] 1.64.0 please test master snapshot..

Boost - Dev mailing list
On 18 Mar 2017 14:02, "Peter Dimov via Boost" <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [release] 1.64.0 please test master snapshot..

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, Mar 18, 2017 at 7:41 AM, Peter Dimov via Boost <
[hidden email]> wrote:

> Olaf van der Spek wrote:
>
>> On Sat, Mar 18, 2017 at 4:06 AM, Tom Kent via Boost <
>> [hidden email]> 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$(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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [release] 1.64.0 please test master snapshot..

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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. :-)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [release] 1.64.0 please test master snapshot..

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Tom Kent wrote:

> On Sat, Mar 18, 2017 at 7:41 AM, Peter Dimov via Boost
> <[hidden email]> 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.


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