- Boost - lists.boost.org

[asio] Issues piling up
by Vinnie Falco 20 Oct '18

20 Oct '18

There are issues which are years old which have been lingering in the Boost.Asio repository, and there are also old issues in the stand-alone Asio repository. It seems like these are being ignored, is there any strategy for addressing this? Examples: This one is going on a year: <https://github.com/boostorg/asio/issues/77> Two years: <https://github.com/chriskohlhoff/asio/issues/124> Thanks

10 16

Re: [boost] Fwd: Installing CMake configuration files
by Peter Dimov 20 Oct '18

20 Oct '18

> Yeah, I haven't been able to figure this part out. How do I pass the > $(sources) from generate-cmake-variant to generate-cmake-variant-'s > sources? The sources - in this case $(lib-target) go here, after `non-scanning-action`: local a = [ new non-scanning-action $(lib-target) : boost-install.generate-cmake-variant- : $(property-set) ] ; :-)

1 0

Installing CMake configuration files
by Peter Dimov 19 Oct '18

19 Oct '18

I've taken another stab at installing CMake configuration files along with the libraries in `b2 install`. CMake configuration files are .cmake files, typically installed into $prefix/lib or $prefix/lib/cmake, that allow f.ex. `find_package(boost_system)` in a CMakeLists.txt file to find the installed Boost.System library and declare a CMake target Boost::system that refers to it. CMake targets can then link to Boost::system and all is well. The work in its current state is available on the feature/cmake-config branch of the superproject: git clone --recursive -b feature/cmake-config https://github.com/boostorg/boost cd boost bootstrap b2 --prefix=... install After that .../lib should contain the libraries and .../lib/cmake - the config files. Then from CMake cmake -DCMAKE_INSTALL_PREFIX=... .. as usual. See for example the test scripts at https://github.com/boostorg/boost_install/blob/master/.travis.yml#L60 and https://github.com/boostorg/boost_install/blob/master/appveyor.yml#L40 Since `b2 install` installs more than one library variant, the CMake configurations need to pick the correct one and to do so look at (a subset of) the FindBoost-compatible variables as described at: https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake#L122 Boost_USE_DEBUG_LIBS, Boost_USE_RELEASE_LIBS, Boost_USE_STATIC_LIBS, Boost_USE_STATIC_RUNTIME, Boost_COMPILER, Boost_DEBUG are honored and have the same meaning as in FindBoost. Boost_USE_MULTITHREADED and Boost_USE_DEBUG_RUNTIME are presently ignored, but probably shouldn't be. :-) The default of Boost_USE_STATIC_LIBS being OFF is a bit inconvenient on Windows, where without `--build-type=complete` our installation only gives you static libraries, and there are suggestions to respect it being ON or OFF, but when not set, to look at BUILD_SHARED_LIBS instead. Under the hood this represents a refactoring of the current centralized installation approach in which the superproject staged and installed the libraries on `b2 stage` and `b2 install`. Now the top level stage and install targets just delegate to each library's stage and install targets, which are responsible for staging/installing that particular library, its CMake config, and its dependencies. These library-level stage and install targets are created by the helper b2 rule boost-install, which already existed (in Jamroot), but is now much enhanced and lives in its own module tools/boost_install. In addition, a metalibrary libs/headers is introduced, which corresponds to the headers as present in a release (in subdirectory boost/) or as installed by `b2 install`. Its install target, in fact, installs the headers, and its stage target, currently empty, should probably assume the function of linking the headers (which at the moment also lives in Jamroot.) At some future point, when we decide to switch to releasing the headers in their original libs/$lib/include locations, the install target of a library will just copy that library's headers; but we aren't there yet. The header-only libraries are used from CMake by finding the package boost_headers and linking to the target Boost::headers. I've deliberately not done anything about Boost::boost and find_package(Boost), to allow FindBoost.cmake to delegate to the config files if present (when Boost 1.69/1.70 or higher is installed), while preserving backward compatibility (when 1.68 or lower is installed.)

6 13

test message - please ignore
by Robert Ramey 19 Oct '18

19 Oct '18

just to see if my newsgroup interface is working. Robert Ramey

1 0

[python] Checking Python version
by Edward Diener 18 Oct '18

18 Oct '18

How do I check the Python major version in code when using Boost.Python ? I know there is a way to do it through a preprocessor define by including the CPathon patchlevel.h file but I would rather not include low-level Python files if Boost.Python has some way of doing it.

2 1

[test] How to execute shell commands
by Mike Dev 18 Oct '18

18 Oct '18

As an extension to my previous question: Does the boost test framework provide an integrated mechanism to get the binary directory (the directory where the currently running test executable is placed) and/or the source directory (where the jam-file resides that defined the test)? Best Mike

4 5

[intrusive] static_assert(sizeof(caster)==sizeof(int))
by Vinnie Falco 18 Oct '18

18 Oct '18

A user is reporting a static assert on compilation: <https://github.com/boostorg/beast/issues/1270> Any ideas? Thanks

2 1

Boost header isolation testing
by James E. King III 16 Oct '18

16 Oct '18

In the winapi project there's a neat little Jamfile rule that will ensure each public header will compile properly (i.e. it is not missing any #include statements). I pulled this into uuid when I started maintaining it, and I find myself pulling it into another repository. It would be nice to have this as a standard Boost.Build rule that one could easily add to test Jamfiles. Is there anything like this that exists right now in Boost.Build? - Jim

6 9

Boost CMake support - Request for Comment
by Robert Ramey 16 Oct '18

16 Oct '18

Background ========== My personal knowledge of build systems is somewhat limited. a) I don't really understand CMake all that well. I have made CMakeLists.txt files for both the serialization library and the safe numerics libraries as an aid to build and maintain IDE and make files used in running tests and posting results to CDash. b) I don't really understand our current system, Boost Build, very well either. I've made jam files for building and running tests for the serialization and safe numerics libraries. c) I recently reviewed C++Now 2017: Daniel Pfeifer's excellent video from C++Now 2017 “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk . I recommend it highly. Despite my lack of knowledge in this area, or perhaps because of it, I've volunteered to direct the effort to evolve Boost so that users of Boost can avail themselves of the benefits of CMake. This effort will be organized as follows: a) A discussion on the boost developers mailing list with the goal of reaching a consensus as to what benefits CMake can and should provide to users and developers of Boost. This effort will commence with the posting of this notice. I hope that this discussion can be more or less resolved within 30 days. b) I will then synthesize from the above discussion a call for proposals which lists the requirements and requirements. c) Those proposing CMake for boost will have approximately 90 days to prepare their proposals. Their proposal are expected to look similar to a boost library proposal. That is they are expected to have some (CMake) code, along with tests, documentation including tutorials and reference. This is only an expectation. It's conceivable that such a proposal might only contain conventions and and samples of what boost library should contain to fulfill the requirements. As with boost libraries, submissions are not required to totally complete. But they have to be sufficiently complete to convince reviewers the the submission fulfills the stated requirements and can be finished in good time. d) After the 90 day period, submissions will be reviewed simultaneously. Note that this is at a variance from normal boost procedure of reviewing submissions one at a time. Since we expect to receive a number of submissions and only one can be accepted, the normal boost protocol can't really function. Target date for this review is 1 February 2019. e) After the review period the review manager will prepare a report which includes the decision of which submission will be accepted into the official boost distribution. Currently, I, Robert Ramey, expect to be review manager. However, it's possible that this by the time the review is undertaken, this coveted position could be assigned to some more worthy candidate. Scope, Requirements and Features ================================ We presume that submissions will fulfill the applicable requirements of any boost submission. In addition we would like to see the following addressed. Library Build ------------- “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk Recommends that all libraries - including header only libraries have a CMakeList.txt file. What should this include for Boost Libraries? Library Test ------------ Should facilities for "testing" be only done by developers? or should users who acquire library packages also be able to test libraries. Should CMake testing results posting be used - CDASH? Should we just skip the issue of Library Testing and continue to depend on Boost Build. Library Packaging ----------------- Is the library packaging facility provide by CMake - CPACK - useful to boost. Should boost libraries be updated to support it? Dependencies ------------ If the above is implemented, can we depend upon CMake to handle library dependencies? Or does some special functionality Do circular dependencies constitute a problem? Modularity ---------- Currently boost is organized as a tightly integrated group of libraries. This organization manifests itself in a number of ways. We have a Boost "super project" in github. Boost libraries are "sub projects" of this super project. This known structure is exploited by and depended upon by boost tools. Should CMake support continue this policy/design. We distribute boost as "super project". Should we continue to do this or distribute libraries on a library by library basis. Does CMake/CPACK etc. make this "simple"? Documentation/testing --------------------- What support should be require for uses of Boost CMake implementation. Documentation, examples, templates for helping library developers. How should the CMake design/implementation be tested? Other considerations -------------------- add your requirement/features here. Useful Resources =============== “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1 https://github.com/purpleKarrot/Boost.CMake https://www.youtube.com/watch?v=eC9-iRN2b04 Please try to keep this discussion on this list. I know that there has been a lot going on on slack. But having it in two places makes it harder for me to review and summarize. Also slack doesn't conveniently maintain comment hierarchy. So please try to keep this discussion on this list. Robert Ramey

15 47

Re: [boost] "peer reviewed" - Rights and responsibilities of maintainers
by Bjorn Reese 16 Oct '18

16 Oct '18

On 10/16/18 9:59 AM, Alexander Grund via Boost wrote: > So again: What is the Boost course on reviews of existing libraries and > the statement on the rights and responsibilities of maintainers? https://www.boost.org/community/reviews.html#Maintainer

4 4