BJAM and VS2013RC
Has anyone successfully built Boost 1.54 with VS2013RC? Did you have an issue with the build process locating cl ? Steven LeMay Game Platform Engineering International Game Technology 9295 Prototype Way Reno, NV 89521 Office: +1 775.448.8089 Mobile: +1 775.813.6676 steven.lemay@igt.com<mailto:steven.lemay@igt.com> This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Any humorous implications are purely the result of misinterpretations provided by the reader.
On Wed, Sep 18, 2013 at 6:00 PM, LeMay.Steve <Steve.Lemay@igt.com> wrote:
Has anyone successfully built Boost 1.54 with VS2013RC?****
**
Did you have an issue with the build process locating cl ?
I tried but it can't work with boost 1.54 because b2 (bjam) don't have the VC12 infos, but it have been added in the svn early. So basically, if you get the trunk svn or wait for Boost 1.55 is published, then yes no problem compiling with VS2013 RC. I'm using the trunk svn right now (from the beginning of last week) with no problem so far.
Check this out: http://stackoverflow.com/questions/17440810/how-do-i-build-boost-with-new-vi... In the accepted answer, you can look at option number 2. I applied the patch the user mentioned in Windows 7 with Visual Studio 2013 RC, and I was able to compile all but 8 of the boost targets (I can't remember which 8, but there were 8 that 'failed'). Patch file can be found here: https://svn.boost.org/trac/boost/attachment/ticket/8750/vc12.patch cheers Jarrett On 18/09/13 12:28 PM, Klaim - Joël Lamotte wrote:
On Wed, Sep 18, 2013 at 6:00 PM, LeMay.Steve <Steve.Lemay@igt.com> wrote:
Has anyone successfully built Boost 1.54 with VS2013RC?****
**
Did you have an issue with the build process locating cl ? I tried but it can't work with boost 1.54 because b2 (bjam) don't have the VC12 infos, but it have been added in the svn early. So basically, if you get the trunk svn or wait for Boost 1.55 is published, then yes no problem compiling with VS2013 RC. I'm using the trunk svn right now (from the beginning of last week) with no problem so far.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Wed, Sep 18, 2013 at 09:00:03AM -0700, LeMay.Steve wrote:
Has anyone successfully built Boost 1.54 with VS2013RC?
Did you have an issue with the build process locating cl ?
Most of the patches mentioned in [1] are still needed against 1.54 in order to build and use 2013 (Preview and RC). The Build one ought to be all you need to get a Boost.Build build and a Boost build going. The rest are ones that you need to get Boost.Config and assorted libraries going. Among them, I think pretty much only the Boost.Build patch has been applied to trunk, the rest are suffering either from quabbling about whether to support non-release compilers or plain neglect. With all those patches applied (with an additional patch [2] adjusting the _MSC_FULL_VER and adding support for the four additional feature macros for 2013RC), my Boost 1.54 tree seems to build completely. <rant> It's still utterly impossible to run the regression test suite as a mere mortal, so I have no idea what kind of regressions there are in Boost between 2012 and 2013RC. I'd like to put more effort into getting support for this upstream, but it's way too frustrating to go through the effort to make decent patches and have the majority of them ignored. I wouldn't expect any form of formal support in Boost for VS 2013 until whatever version releases after the 2013 RTM in November, way too late for any actionable bug reports to Microsoft. I guess some of the compilers are just less important than others. </rant> I uploaded my largely untested and unsupported builds of my patched 1.54.0 built with 2013 RC to [2] and [3], for anyone foolish enough to try it. It has most of the variants I care about: (runtime-link=shared, link=static,shared) [1] http://boost.2283326.n4.nabble.com/Patch-bonanza-for-VS2013-Preview-support-... [2] https://www.acc.umu.se/~zao/boost/boost-1.54.0_vc12_32_patched.7z [3] https://www.acc.umu.se/~zao/boost/boost-1.54.0_vc12_64_patched.7z [4] ---8<--- // C++ features supported by VC++ 12 RC (aka 2013) #if _MSC_FULL_VER < 180020827 #define BOOST_NO_CXX11_DECLTYPE_N3276 #define BOOST_NO_CXX11_DEFAULTED_FUNCTIONS #define BOOST_NO_CXX11_DELETED_FUNCTIONS #define BOOST_NO_CXX11_TEMPLATE_ALIASES #endif ... // last known and checked version is 1800.20827 (VC12 RC, aka 2013 RC): #if (_MSC_VER > 1800 || _MSC_FULL_VER > 180020827) ---8<--- -- Lars Viklund | zao@acc.umu.se
On 18 Sep 2013 at 19:05, Lars Viklund wrote:
Among them, I think pretty much only the Boost.Build patch has been applied to trunk, the rest are suffering either from quabbling about whether to support non-release compilers or plain neglect.
I've been running VS2013 RC last few days with the following additional features above and beyond VS2013 Preview turned on: //#define BOOST_NO_CXX11_DECLTYPE_N3276 //#define BOOST_NO_CXX11_DEFAULTED_FUNCTIONS //#define BOOST_NO_CXX11_DELETED_FUNCTIONS //#define BOOST_NO_CXX11_TEMPLATE_ALIASES It does seem to work. Mostly. I say "mostly" because decltype() isn't a 100% equivalent to GCC or clang's decltype(), so while VS2013's decltype is much better than before, it still falls down. Yesterday I spent some hours trying to get decltype to grok lambda types for example. I eventually gave up - VS2013 kept getting upset about "lambda types aren't constructible" etc. GCC and clang (going back to 4.6 and 3.1) on the other hand fly past this with ease.
It's still utterly impossible to run the regression test suite as a mere mortal, so I have no idea what kind of regressions there are in Boost between 2012 and 2013RC.
I'd like to put more effort into getting support for this upstream, but it's way too frustrating to go through the effort to make decent patches and have the majority of them ignored.
I wouldn't expect any form of formal support in Boost for VS 2013 until whatever version releases after the 2013 RTM in November, way too late for any actionable bug reports to Microsoft.
I think the caution is warranted. VS2013 is quite a different beastie to VS2012. A good few months of testing is definitely in order. I don't know if Stephen is reading this, but if he is, does Microsoft flip on these features in Boost themselves to see how their compiler runs? I'd assume they do. Regarding the breakage of std::result_of<> in VS2013 under variadic templates, in AFIO I ended up with this stupid line: #if _MSC_VER == 1800 // specifically VS2013 only use preprocessor generated overloads; #else use variadic template overloads; #endif I could work around SFINAE failure during variadic template overload resolution on every single compiler we support except for specifically VS2013 only, on which I gave up after many hours of head bashing because its decltype() seems to me to be a bit brittle as compared to other compilers (perhaps this is the letter of the standard, though I thought decltype() gets much more relaxed in C++14). I had a crack with Eric's decltype() based SFINAE capable boost::result_of instead of std::result_of, but there I got different breakages of overload resolution. Anyway I've slept on it last night and I now have a new idea for working around the problem so I can switch on variadic template overloads in AFIO on VS2013. It is annoying that it's this hard though, what I'm doing is a common use case many others will encounter when writing C++11. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
VS2013RC does have deleted and default functions. Sent from my iPhone On 19 Sep 2013, at 17:20, "Niall Douglas" <s_sourceforge@nedprod.com> wrote:
On 18 Sep 2013 at 19:05, Lars Viklund wrote:
Among them, I think pretty much only the Boost.Build patch has been applied to trunk, the rest are suffering either from quabbling about whether to support non-release compilers or plain neglect.
I've been running VS2013 RC last few days with the following additional features above and beyond VS2013 Preview turned on:
//#define BOOST_NO_CXX11_DECLTYPE_N3276 //#define BOOST_NO_CXX11_DEFAULTED_FUNCTIONS //#define BOOST_NO_CXX11_DELETED_FUNCTIONS //#define BOOST_NO_CXX11_TEMPLATE_ALIASES
It does seem to work. Mostly.
I say "mostly" because decltype() isn't a 100% equivalent to GCC or clang's decltype(), so while VS2013's decltype is much better than before, it still falls down.
Yesterday I spent some hours trying to get decltype to grok lambda types for example. I eventually gave up - VS2013 kept getting upset about "lambda types aren't constructible" etc. GCC and clang (going back to 4.6 and 3.1) on the other hand fly past this with ease.
It's still utterly impossible to run the regression test suite as a mere mortal, so I have no idea what kind of regressions there are in Boost between 2012 and 2013RC.
I'd like to put more effort into getting support for this upstream, but it's way too frustrating to go through the effort to make decent patches and have the majority of them ignored.
I wouldn't expect any form of formal support in Boost for VS 2013 until whatever version releases after the 2013 RTM in November, way too late for any actionable bug reports to Microsoft.
I think the caution is warranted. VS2013 is quite a different beastie to VS2012. A good few months of testing is definitely in order. I don't know if Stephen is reading this, but if he is, does Microsoft flip on these features in Boost themselves to see how their compiler runs? I'd assume they do.
Regarding the breakage of std::result_of<> in VS2013 under variadic templates, in AFIO I ended up with this stupid line:
#if _MSC_VER == 1800 // specifically VS2013 only use preprocessor generated overloads; #else use variadic template overloads; #endif
I could work around SFINAE failure during variadic template overload resolution on every single compiler we support except for specifically VS2013 only, on which I gave up after many hours of head bashing because its decltype() seems to me to be a bit brittle as compared to other compilers (perhaps this is the letter of the standard, though I thought decltype() gets much more relaxed in C++14). I had a crack with Eric's decltype() based SFINAE capable boost::result_of instead of std::result_of, but there I got different breakages of overload resolution.
Anyway I've slept on it last night and I now have a new idea for working around the problem so I can switch on variadic template overloads in AFIO on VS2013. It is annoying that it's this hard though, what I'm doing is a common use case many others will encounter when writing C++11.
Niall
-- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Thu, Sep 19, 2013 at 05:26:22PM +0100, Craig Henderson wrote:
VS2013RC does have deleted and default functions.
Sent from my iPhone
On 19 Sep 2013, at 17:20, "Niall Douglas" <s_sourceforge@nedprod.com> wrote:
On 18 Sep 2013 at 19:05, Lars Viklund wrote:
Among them, I think pretty much only the Boost.Build patch has been applied to trunk, the rest are suffering either from quabbling about whether to support non-release compilers or plain neglect.
I've been running VS2013 RC last few days with the following additional features above and beyond VS2013 Preview turned on:
//#define BOOST_NO_CXX11_DECLTYPE_N3276 //#define BOOST_NO_CXX11_DEFAULTED_FUNCTIONS //#define BOOST_NO_CXX11_DELETED_FUNCTIONS //#define BOOST_NO_CXX11_TEMPLATE_ALIASES
I believe that Niall, like me in my post, meant that these negative feature macros shall be non-defined when targetting 2013RC. The omission of a negative feature macro implies that the feature is supported. -- Lars Viklund | zao@acc.umu.se
On 20 Sep 2013 at 1:47, Lars Viklund wrote:
//#define BOOST_NO_CXX11_DECLTYPE_N3276 //#define BOOST_NO_CXX11_DEFAULTED_FUNCTIONS //#define BOOST_NO_CXX11_DELETED_FUNCTIONS //#define BOOST_NO_CXX11_TEMPLATE_ALIASES
I believe that Niall, like me in my post, meant that these negative feature macros shall be non-defined when targetting 2013RC.
The omission of a negative feature macro implies that the feature is supported.
Correct. Sorry for being unclear, I should have emphasised the fact I had commented them out. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
participants (4)
-
Craig Henderson -
Jarrett Chisholm -
Klaim - Joël Lamotte -
Lars Viklund -
LeMay.Steve -
Niall Douglas