- Boost - lists.boost.org

[release] 1.69.0 closed for major changes
by Marshall Clow 01 Nov '18

01 Nov '18

The master branch is now closed for new libraries and breaking changes, and will be closing for the beta in one week. Also, if you're ready, you can also add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_69_0.q… > After editing the release notes, you should get a form to create a pull request, remember to submit it, otherwise I won't see your change. Thanks, -- The Boost Release Team

1 0

clang-win, again
by Peter Dimov 31 Oct '18

31 Oct '18

Has anyone succeeded in getting clang-cl.exe working under b2? I've installed llvm-6.0.1, added it to PATH, put using clang-win : : : <compatibility>vc14 ; in my user-config, and what I get is: C:\boost-git\develop\libs\smart_ptr\test>b2 toolset=clang-win sp_interlocked_test warning: mismatched versions of Boost.Build engine and core warning: Boost.Build engine (b2) is 2015.07.00 warning: Boost.Build core (at C:/boost-git/develop/tools/build/src) is 2018.02-git C:/boost-git/develop/tools/build/src/tools\msvc.jam:1087: in set-setup-command *** argument error * rule virtual-target.from-file ( file : file-loc : project ) * called with: ( : /C:/boost-git/develop/libs/smart_ptr/test : object(project-t arget)@129 ) * missing argument file C:/boost-git/develop/tools/build/src/build\virtual-target.jam:970:see definition of rule 'virtual-target.from-file' being called C:/boost-git/develop/tools/build/src/tools\msvc.jam:652: in clang-win.compile.c+ + C:/boost-git/develop/tools/build/src/kernel\modules.jam:107: in modules.call-in C:/boost-git/develop/tools/build/src/util\indirect.jam:105: in indirect.call C:/boost-git/develop/tools/build/src/build\virtual-target.jam:902: in execute C:/boost-git/develop/tools/build/src/build\virtual-target.jam:821: in class@acti on.actualize C:/boost-git/develop/tools/build/src/build\virtual-target.jam:332: in actualize- action C:/boost-git/develop/tools/build/src/build\virtual-target.jam:518: in actualize- no-scanner C:/boost-git/develop/tools/build/src/build\virtual-target.jam:142: in class@virt ual-target.actualize C:/boost-git/develop/tools/build/src/build\configure.jam:258: in try-find-build C:/boost-git/develop/tools/build/src/build\configure.jam:396: in find-builds-raw C:/boost-git/develop/tools/build/src/build\configure.jam:455: in configure.find- builds C:/boost-git/develop\boostcpp.jam:734: in boostcpp.deduce-address-model C:/boost-git/develop/tools/build/src/kernel\modules.jam:107: in modules.call-in C:/boost-git/develop/tools/build/src/util\indirect.jam:105: in indirect.call C:/boost-git/develop/tools/build/src/build\property.jam:144: in property.evaluat e-conditionals-in-context C:/boost-git/develop/tools/build/src/build\targets.jam:1087: in evaluate-require ments C:/boost-git/develop/tools/build/src/build\targets.jam:1121: in common-propertie s2 C:/boost-git/develop/tools/build/src/build\targets.jam:1017: in targets.common-p roperties C:/boost-git/develop/tools/build/src/build\targets.jam:1313: in class@basic-targ et.generate C:/boost-git/develop/tools/build/src/build\targets.jam:812: in generate-really C:/boost-git/develop/tools/build/src/build\targets.jam:784: in class@main-target .generate C:/boost-git/develop/tools/build/src\build-system.jam:797: in load C:\boost-git\develop\tools\build\src/kernel\modules.jam:295: in import C:\boost-git\develop\tools\build\src/kernel/bootstrap.jam:139: in boost-build C:\boost-git\develop\boost-build.jam:17: in module scope

9 74

[property-tree] state of the library, fixes and extensions
by Goehring, Christian 31 Oct '18

31 Oct '18

Hi @all, the property-tree lib seems to be in some sort of dormant state judging from the repository activity. Is this library still actively maintained (for example, the xml-functionality would need some support for CData)? Do you know if there is any need for extensions (for example JSON-support) or did some other alternative succeed this library? Thanks in advance! Best, Christian

1 0

questions regarding visibility and b2
by Robert Ramey 30 Oct '18

30 Oct '18

I've got a few questions about the "visibility" changes for boost. My understanding is that "visibility" for gcc and clang are "sort of the same thing" as dll import and export are for windows. Now we've made "visibility" the "default". But this seems kind of weird. This has been made a b2 feature. In order to run tests, this feature is applied to the b2 command line. What's weird is that it's applied to the tests/executables and propogated down to libraries which are built. I actually don't know what "visibility" means in the context of building and executable. If I want to use visibility=global then on the library build, it needs to be applied to everything. It's very weird and doesn't seem in line with the windows solution. Heretofore, I've applied visibility to the library build "by hand" by adding the appropriate command line switches to the right places. I'm aware that this is not the b2 way. But the b2 way doesn't seem to make sense to me. On the bright side, changing default visibility didn't seem to have any effect on the serialization library other than on one test. Unfortunately, turning this confused a pending issue and made it even more contentious than it already is/was. FWIW - this is not so much the fault of b2 or anyone in particular. The use of DLLS/shared libraries is the triumph of development over design by vendors, each of whom do their own thing and have never been able to get it together. By now this has created enough technical debt that it will take years to straighten out if people actually start to address it, which no one seems interest in doing. Anyway, the b2 approach is pretty confusing and probably wrong. I'm also guessing that, as one would predict, a change like this is going to provoke subtle failures in lots of small corners which will take quite a while to discover. I'm not sure how to address this. Robert Ramey

4 5

[release] 1.69.0 deadline for new libraries approaching
by Marshall Clow 29 Oct '18

29 Oct '18

It's that time again! On Wednesday, the master branch will be closed for adding new libraries. Upcoming dates: * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes * 31-Oct: Boost 1.69.0 closed for major code changes * 7-Nov: Boost 1.69.0 closed for beta * 14-Nov: Boost 1.69.0 beta 1 * 5-Dec: Boost 1.69.0 closed for release * 12-Dec: Boost 1.69.0 release -- The Boost Release Team

7 10

Is boost supported on z/os
by Naveen Sharma 28 Oct '18

28 Oct '18

Hello Does boost supported on z/os or may be subset of library. We are planning to replace our current library with boost. One of the platform we support is z/os and so I am researching if boost can be compiled and usable on the platform. I did searched on the internet but did not get much information. Before I dive into it, I thought to ask. Thanks Naveen

2 2

Re: [boost] [histogram] Objections against switch to C++14?
by Bjorn Reese 28 Oct '18

28 Oct '18

On 10/22/18 6:42 PM, Hans Dembinski wrote: > Do you object against raising the requirement from C++11 to C++14 for the implementation of boost.histogram? No objection from my side. However, you may consider making parts of the library available to C++11 users, because there are plenty of those out there.

1 0

Builds from boost/status fail early?
by James E. King III 27 Oct '18

27 Oct '18

Using develop from this morning (tried various combinations of these three options...): boost@d48d3305d4b4:/boost/status$ ../b2 toolset=clang variant=release cxxstd=03 ... /boost/tools/build/src/build/feature.jam:491: in validate-value-string from module feature error: "shared:" is not a known value of feature <link> error: legal values: "shared" "static" /boost/tools/build/src/build/feature.jam:365: in expand-subfeatures-aux from module feature /boost/tools/build/src/build/feature.jam:422: in expand-subfeatures from module feature /boost/tools/build/src/build/feature.jam:871: in feature.expand from module feature /boost/tools/build/src/build/targets.jam:1103: in evaluate-requirements from module targets /boost/tools/build/src/build/targets.jam:1121: in common-properties2 from module targets /boost/tools/build/src/build/targets.jam:1017: in targets.common-properties from module targets /boost/tools/build/src/build/targets.jam:1313: in class(a)basic-target.generate from module object(typed-target)@47912 /boost/tools/build/src/build/targets.jam:812: in generate-really from module object(main-target)@70272 /boost/tools/build/src/build/targets.jam:784: in class(a)main-target.generate from module object(main-target)@70272 /boost/tools/build/src/build/targets.jam:273: in class(a)project-target.generate from module object(project-target)@47307 /boost/tools/build/src/build/targets.jam:273: in class(a)project-target.generate from module object(project-target)@4568 /boost/tools/build/src/build-system.jam:797: in load from module build-system /boost/tools/build/src/kernel/modules.jam:295: in import from module modules /boost/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module /boost/boost-build.jam:17: in module scope from module

3 12

[statechart] visibility change broke things
by James E. King III 27 Oct '18

27 Oct '18

Boost.StateChart wasn't building on a regular basis. It looks like the visibility changes broke it. I opened an issue for it. I also changed Travis CI to build it monthly.

1 0

[serialization] boost:array
by Yuval Lifshitz 27 Oct '18

27 Oct '18

Any idea on why was the serializer for boost:array removed?Can we re-introduce it? Yuval Lifshitz

1 0