- Boost - lists.boost.org

[VS++ 2015 CTP 6] [build] Workaround for Visual Studio 2015 CTP 6 Preview breaking Boost.Build
by Beman Dawes 02 Apr '15

02 Apr '15

If you have previously been running Boost.Build on toolset=msvc-14.0 (Visual Studio 2015 Preview), installing CTP 6 causes some bjam/b2 builds to fail because of missing include files. What's happening is that Boost.Build caches several files in C:\Users\<name>\AppData\Local\Temp. For my installation these files are: b2_msvc_14.0_vcvarsall_x86.cmd b2_msvc_14.0_vcvarsall_x86_amd64.cmd b2_msvc_14.0_vcvarsall_x86_arm.cmd but the introduction of the new universal runtime stuff in CTP 6 added some additional paths to vcvarsall, so the cached files are no longer correct. The workaround is to simply delete the b2_msvc_14.0_vcvarsall* temporary files. The next time bjam/b2 is run correct versions of the files will be regenerated. --Beman

1 0

[rational] Can the community maintenance team and/or rational users please review some pull requests?
by John Maddock 02 Apr '15

02 Apr '15

I have a bunch of PR's against Rational, which of course is basically unmaintained. I'd be grateful if a second pair of eyes (at least) could take a look before I start agitating for someone to merge them ;) Each of the four, builds on the previous one(s). Three are basically trivial: https://github.com/boostorg/rational/pull/1/files https://github.com/boostorg/rational/pull/2/files https://github.com/boostorg/rational/pull/3/files The final one is much more complex, and disables "accidental" conversion from float to rational (which otherwise proceeds via truncation to integer first). As you can see from the commit history, I've had quite a few attempts at getting the final one correct. I believe it is now, doesn't break anything in Boost except, as noted in the discussion, Boost.Geometry, which relies on an unsafe float to rational conversion - Geometry's authors are aware of the issue here: https://github.com/boostorg/geometry/commit/c992eb61e8ef9e90fdae403ac6ff1ee…. So.... I'm interested in both eyeball-look-throughs from seasoned Boosters, but also feedback from Rational's users, and verification that it doesn't break end user code - other than unsafe conversions of course. If you just want the updated header to test, you can grab it from here: https://raw.githubusercontent.com/jzmaddock/rational/no-float-convert/inclu… Many thanks! John.

5 8

MPL and MPL core
by Edward Diener 02 Apr '15

02 Apr '15

Were the changes to MPL splitting it between a core and the rest of MPL supposed to be part of the upcoming release ? Because looking at MPL the 'master' branch is at the previous 1.57 release and there have been quite a number of changes to the 'develop' branch since then, much of it relating to the mpl/core split. The 'develop' regression tests for MPL look pretty green. I would like to get bruno Dutra's fix for MPL arity into the coming release as it has been thoroughly tested on 'develop', but I do not know whether or not all the other MPL 'develop' changes should go in 'master' although I suspect not.

11 20

questions regarding GCC visibility
by Robert Ramey 02 Apr '15

02 Apr '15

I made a few changes to simplify code in the serialization library. This entailed eliminating support for borland compilers, workarounds for compilers which fail to support partial specialization of template function and some general clean up. In the course of this effort, I had occasion to simplify the code which supports Auto linking - and by extension visibility. Things seemed to go pretty well. Feeling frisky, I added the switch -fvisibility=hidden to the gcc compile of library. Now applications won't link for lack of certain symbols. Well, they link and run fin on my machine here at home- but fail in the test matrix. http://www.boost.org/development/tests/develop/developer/output/Debian-Sid-… Funny thing is: doesn't seem to be a problem on my machine doesn't seem to occur with all exported symbols - only select ones - often but not always desctructors I can switch Jamfile back so it doesn't specify -fvisibility=hidden, but it seems that I'm really close to being able to generate a smaller, cleaner DLL which I would prefer to do. Any constructive suggestions would be appreciated. On a related note, it seems to me that http://www.boost.org/development/separate_compilation.html should be updated to explain BOOST_SYMBOL_EXPORT and BOOST_SYMBOL_IMPORT which are convenient for simplifying the auto-linking and visibility functionality. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/questions-regarding-GCC-visibility-tp467… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 10

Boost 1.58.0rc1 release delayed
by Marshall Clow 01 Apr '15

01 Apr '15

Due to some problems in Boost.Test, and some unexpected doctor's visits (which delayed said problems getting fixed), the boost 1.58.0rc1 scheduled for today has been delayed until Friday. As a result, the "master" branch in git is still open for bug fixes (if they have been successfully tested on develop) and documentation fixes until 11:59 PM PDT Thursday night (4/2). Sorry for the delay. -- Marshall

2 1

what happened to the "tools/regression" directory - and the stuff in it?
by Robert Ramey 01 Apr '15

01 Apr '15

The tools in the tools/regression directory are critical to the testing of the serialization library on one's local machine. What happened to these. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/what-happened-to-the-tools-regression-di… Sent from the Boost - Dev mailing list archive at Nabble.com.

9 26

[boostorg/regression] Build instructions updated for developers local test reporting
by Beman Dawes 01 Apr '15

01 Apr '15

A README file has been added and index.html updated to aid developers wishing to use these tools for local testing. While these tools are not worthwhile for a small number of tests run against a single variant of a single compiler, they are invaluable for large test matrices. See develop branch at https://github.com/boostorg/regression HTH, --Beman

2 1

Test message testing gsoc-admin@boost.org, please ignore
by Niall Douglas 01 Apr '15

01 Apr '15

Second attempt at getting this to work ... --- Boost C++ Libraries Google Summer of Code 2015 admin https://svn.boost.org/trac/boost/wiki/SoC2015

1 0

[log] [asio] Conflicting default configs
by Andrey Semashev 01 Apr '15

01 Apr '15

Hi, In Boost.Log I'm using Boost.ASIO to implement network-based syslog backend. Boost.ASIO is used in the compiled part of Boost.Log and, obviously, can be used in the user's code as well. By default Boost.ASIO is header-only, so we basically have a copy of Boost.ASIO in Boost.Log and another copy in the user's app. In Boost.Log I have the option to enable compiler-based TLS at the library build stage (BOOST_LOG_USE_COMPILER_TLS macro), which is by default not enabled. In Boost.ASIO there is a similar option (BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION macro) but the feature is enabled by default. I want Boost.Log built libraries to actually respect the BOOST_LOG_USE_COMPILER_TLS option, so I define BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION internally when BOOST_LOG_USE_COMPILER_TLS is not defined. The problem is that Boost.ASIO changes implementation in an incompatible way when BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION is defined. It is further worsened by a recent change that makes all of Boost.ASIO symbols externally visible. Basically, this means hard to debug trouble on user's end, when different versions of Boost.ASIO (one from Boost.Log binaries and the other used by the user's code directly) are used at the same time. I'd like to ask community what is the preferred resolution of this situation (and possibly similar ones in the future). I can see several ways of tackling this: 1. Introduce an inline ABI namespace in Boost.ASIO, much like the one I have in Boost.Log. The namespace name would depend on BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION and other macros that affect binary compatibility. This would be my preferred solution, although I'm not sure how fast and easy it can be implemented. 2. Remove symbol visibility enforcement from Boost.ASIO, or at least make it optional. That way I could encapsulate my private copy of Boost.ASIO in Boost.Log binaries. 3. Change the defaults, either in Boost.Log or in Boost.ASIO, so that they are aligned by default. When the user changes Boost.Log config he would be expected to know that Boost.ASIO config also needs to be changed accordingly. If he doesn't, Boost.Log is still built consistently with its own config. Note, however, that since Boost.Log is a built library and in most distributions it is built with default options, the choice for Boost.Log is more significant and because of that should probably be more conservative. 4. Same as 3 but also remove the enforcement of Boost.ASIO config by Boost.Log. Whenever the user wants to change the default, he would have to define macros for the both libraries, otherwise Boost.Log can be built inconsistently. 5. Do not change the defaults but remove the config enforcement. BOOST_LOG_USE_COMPILER_TLS becomes Boost.Log-local and as such does not guarantee that the resulting binaries do not in fact use compiler-based TLS. Users can get surprised. 6. Do not change anything, let the users suffer because of ODR issues. Maybe document this somewhere... Opinions?

5 11

[serialization][release][teeks99] All MSVC tests for Boost.Serialization failing?
by Joaquín M Lopez Munoz 31 Mar '15

31 Mar '15

Hi All teeks99-* regression tests for Boost.Serialization in MSVC compilers appear as failing, yet when one clicks on any the information seems to indicate nothing went wrong: http://tinyurl.com/nf5bd9a Any clue? Thank you Joaquín M López Muñoz Telefónica

3 4