October 2018 - Boost - lists.boost.org

Draft copy - Call for Submissions - CMake for Boost
by Robert Ramey 05 Nov '18

05 Nov '18

The following is a draft of the document of I have planned to post on behalf of Boost on or around 1 November 2018 as the first step in our next attempt to accommodate CMake in Boost. Robert Ramey Call for Submissions - CMake for Boost ====================================== For some time, there has been interest on many users and developers of Boost Libraries to make Boost easier to use with CMake. Discussions in the past have not resulted in an implementation which has been widely accepted. Never the less, hope springs eternal, and we intend to attempt this once again. It seems that often there are difficulties before such projects even start in that there are wide discrepancies as to what should be the goals and expectations of Boost support of CMake. The aim of this document is to try to build a consensus on this question before encouraging CMake developers and experts to submit proposals for Boost support of CMake. Requirements and Scope ====================== Requirements ------------ Submissions will fulfill the applicable requirements of any boost submission. This will include: a) any necessary code. b) specifications/requirements for things like directory structure and contents. b) A useful document. Document should provide information, examples and templates so that a typical C++ and CMake user should be able to do any of the following in a short time - say 10 minutes. Document at a minimum should be viewable as html and/or PDF file. 1) A library user should be able to incorporate a Boost Library into the CMake script. 2) A library user should be able to determine which additional Boost Libraries he needs. 3) A library developer should find it simple to create the requisite CMake files for his library. Thus the documentation should contain explanation and perhaps other means such as examples and/or "templates" for required CMake files. c) test of CMake facilities supported by the CMake implementation. This will include code, test of any features, capabilities that the submission provides. Users expect that if they follow the instructions in the documentation, they will get the promised results. A manner of proving this must be provided. A likely response to this requirement would be a "test project" which can be used to demonstrate that the submission actually works. This will be useful in the future for maintenance of the CMake Boost implementation. It will permit the maintainer of the Boost.CMake facility to work on and test their fixes and improvements without disrupting other developers and users. d) a Boost License Facilities and features ----------------------- CMake as it stands has lots of capabilities. But it has a fair amount of complexity as well. Lots of things can be accomplished in multiple different ways - each with subtly different results and effects. CMake for Boost will likely consist of documentation, examples, CMake code, and other stuff to use CMake to permit new features and facilities for users and developers of Boost libraries. What follows is a list of facilities that Boost users and developers would like to acquire with CMake for Boost. Those marked with * should be considered hard requirements. That is, submissions which don't include this feature can't be considered. Other items are interesting and would be considered if included in a submission. *a) incorporating selected Boost Libraries into a user's application *b) incorporating selected Boost Libraries into a user's library c) building a boost library d) building a boost tool such as Boost.bcp, Boost.boostdep, etc. e) testing a boost library - if testing of Boost libraries is to be supported, the following features should be considered. Those marked * should be considered essential. *1) execution tests - must pass/ must fail *2) compile only tests - must pass/ must fail *3) link only tests - must pass/ must fail 4) should be available to both users and developers 5) should not depend upon tools other than C++. 6) test should have the option of posting the results to some public "dashboard" 7) option for recursive testing and/or building of libraries might be nice. That is if library A uses library B and I test library A, this would automatically test library B beforehand. *f) In CMake, dependent libraries are specified as part of the library CMakeLists.txt files. There several ways to do this and the subject is pretty confusing to get right. Any submission documentation has to explain to library developers how do this. g) Some have suggested a highly automated process including downloading/updating, finding other components on other machines, etc. This shouldn't be considered h) packaging - preparation of distributable, installable files for various operating systems. That is support for the CPack facility. i) There has been a lot interest and work in automatically determining dependencies It's a much deeper subject than most people realize. Solving this problem is not a requirement of the submission. However, submitters are free to address this if they desire. *j) support of library modularity. This would mean: *1) independence of things outside the library directory structure. To wit - no presumption about any "super project". *2) building out of tree *3) no need for installing libraries not used by the build target k) ... Submission Rules and Procedures ------------------------------- a) This document constitutes a "Request for Submissions". It will be announced on the boost announcements list, boost developer's list, slack/boost, isocpp website and twitter account, reddit at r/cpp. Submissions will be open to anyone. b) Submissions will be accepted at an email address to be specified. Received submissions will receive a "prescreening" to determine that they meet the requirements specified for such submissions at the top of this document. Those that don't will be returned to the author. c) The name of the author of a submission will not be included in the submission. Authors will be expected to take reasonable efforts to maintain his anonymity via a github repo without a real name assigned, anonymous, email address etc. We understand that the nature of the submission and debate during subsequent review of the proposals. Never the less we believe that anonymity can be mostly maintained. The the true identity of the author of the selected proposal will not be revealed until the selection is made. The motivation for this anonymity is to attract submitters who find the boost review process distressing, annoying and/or unpleasant. It should also address the concerns of those who beleive that by not being a "boost insider" they won't get fair consideration. Boost is first and foremost a meritocracy. We seek the very best in everything regardless of other considerations. d) Submissions will be closed on or about 1 February 2019. Boost formal review will commence shortly there after. Depending on the number of submissions received, the process may last as long as month. e) As per the boost formal review rules and customs, some time after the review period terminates, the review manager will announce the review results. This will likely contain some conditions regarding alterations required in the submissions implementations. I the author find these too onerous, and declines the opportunity to integrate his submission as an official part of boost, the review manager may select an alternate submission. It's also possible that the review manager may decide to accept none of the submissions. f) when the submission is integrated into boost and is shown fulfill the requirements stipulated by the review manager. The author will receive a "prize" of $5000 and a large but cheap medal on a ribbon hopefully to be awarded at the next C++Now (Boost Con). As this is written, this prize is subject to finding a funding source. It's understood that this stipend is in no way compensation, for all the work and aggravation of this task. But we hope that it will serve as a tangible token of our gratitude for solving one of Boosts most pressing and difficult problems. Useful Resources =============== “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1 https://github.com/purpleKarrot/Boost.CMake https://steveire.wordpress.com/2016/08/21/boost-dependencies-and-bcp/

10 28

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