- Boost - lists.preview.boost.org

The deadline for new libraries and breaking changes in Boost 1.77.0 is this Wednesday, June 23
by Marshall Clow 21 Jun '21

21 Jun '21

See https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> for the full calendar — The Release Managers

1 0

Re: [boost] What has become of John Maddock's implementation of the Remez algorithm for Chebychev approximation?
by Bjorn Reese 18 Jun '21

18 Jun '21

On 6/15/21 11:48 PM, Joachim Wuttke via Boost wrote: > Until v1.53, Boost Math had doc pages [1,2] on the Remez algorithm. > This algorithm [3] computes the coefficents of the Chebyshev polynomial > that approximates a given function. Page [2] refers to actual code In addition to John's reply, I wanted to add that Boost.Math has direct support for Chebyshev polynomials now: https://www.boost.org/doc/libs/release/libs/math/doc/html/math_toolkit/sf_p…

4 5

What has become of John Maddock's implementation of the Remez algorithm for Chebychev approximation?
by Joachim Wuttke 16 Jun '21

16 Jun '21

Until v1.53, Boost Math had doc pages [1,2] on the Remez algorithm. This algorithm [3] computes the coefficents of the Chebyshev polynomial that approximates a given function. Page [2] refers to actual code in directory libs/math/minimax. This code can still be found on GitHub [4], but maintenance status and dependences are unclear. Anybody around who knows anything about this code? Kind regards, Joachim [1] https://www.boost.org/doc/libs/1_53_0/libs/math/doc/sf_and_dist/html/math_t… [2] https://www.boost.org/doc/libs/1_53_0/libs/math/doc/sf_and_dist/html/math_t… [3] https://en.wikipedia.org/wiki/Remez_algorithm [4] https://github.com/boostorg/math/tree/develop/tools/minimax -- Dr. Joachim Wuttke group leader Scientific Computing Forschungszentrum Jülich GmbH Jülich Centre for Neutron Science at MLZ https://computing.mlz-garching.de https://jugit.fz-juelich.de/mlz

2 1

Using Boost.Test header-only from CMake
by Peter Dimov 15 Jun '21

15 Jun '21

Some libraries (I encountered this when porting the tests of Signals2) use Boost.Test in header-only mode, by including <boost/test/included/unit_test.hpp> without linking to anything. This worked in the "legacy" structure where all headers are always available, but doesn't work under CMake where you have to link to header-only libraries in order to get the proper include path. Should we make an attempt to support this use by declaring a special header-only target in Boost.Test (e.g. Boost::included_unit_test), or is that a waste of time? One can as well link to the proper Boost::unit_test_framework (and then even use it header-only, although there's not much point in doing so.) I'm inclined towards "waste of time".

10 34

Re: [boost] boost-json apt-get packge
by Vollaro, John 14 Jun '21

14 Jun '21

Date: Fri, 11 Jun 2021 01:42:18 +0300 From: "Peter Dimov" <pdimov(a)gmail.com> To: <boost(a)lists.boost.org> Subject: Re: [boost] boost-json apt-get packge Message-ID: <05f001d75e49$decba2f0$9c62e8d0$(a)gmail.com> Content-Type: text/plain; charset="utf-8" Vollaro, John wrote: > Is their a apt package that includes boost-json? For what distro? debian > This apt packages did not include boost-json > > apt-get install libboost1.76-all-dev Should be libboost1.76-json-dev. Could not find this package. This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.

2 1

CMake minimum version to support
by Peter Dimov 11 Jun '21

11 Jun '21

I suppose the time has come to have the discussion on the minimum CMake version we will support for building Boost. Currently that's set to 3.5, which kind of works, but is fairly inconvenient. The interesting options are - CMake 3.8: required for use of the compile features cxx_std_11, cxx_std_14, cxx_std_17, etc. Also allows source_group(TREE, which is used by Json and PropertyTree. - CMake 3.9: required by Nowide, I'm not sure why. Also, required for FindMPI to define an imported target. Building Boost.MPI is optional though. - CMake 3.13: required for Boost installation support. - CMake 3.14: required for FindPython to be modern enough to make building Boost.Python reasonably easy. (Building Boost.Python is optional, though.) There are also less important nice-to-have things such as - CMake 3.10: adds include_guard() - CMake 3.12: adds CONFIGURE_DEPENDS to file(GLOB - CMake 3.15: adds VERBOSE/DEBUG to message( Opinions?

15 40

boost-json apt-get packge
by Vollaro, John 10 Jun '21

10 Jun '21

Is their a apt package that includes boost-json? This apt packages did not include boost-json apt-get install libboost1.76-all-dev ____________________________ John Vollaro 185 Asylum St 6th Floor, Hartford, CT 06103 O: 860-702-8563 | M: 860-919-9443 | john.vollaro(a)optum.com<mailto:john.vollaro@optum.com> This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.

2 1

Re: [boost] Using Boost.Test header-only from CMake
by Glen Fernandes 10 Jun '21

10 Jun '21

On Sun, Jun 6, 2021 at 9:51 PM Peter Dimov wrote: > For completeness, the libraries using the deprecated boost/test/minimal.hpp are: > > foreach > graph > graph_parallel > iterator > logic > numeric/conversion > numeric/interval > property_map > tokenizer > units > yap > > These need to migrate to either LWT or the non-deprecated Boost.Test. I've migrated all of the above to LWT. Graph is still a PR that needs to be merged. Glen

1 0

Fwd: Interested in contribution to this organisation.
by Chandrakant Jena 16 09 Jun '21

09 Jun '21

---------- Forwarded message --------- From: Chandrakant Jena 16 <chandrakant.barcelona(a)gmail.com> Date: Wed, Jun 9, 2021 at 9:47 AM Subject: Interested in contribution to this organisation. To: <boost(a)lists.boost.org> hello devs, I am chandrakant jena currently studying computer science in utkal university, bhubaneshwar,Odisha. my current interest is c++ and I found this organisation really interesting and suitable for me. I want to know how can I get started? here are some of my profile links: linked in: https://www.linkedin.com/in/chandrakant-jena-5aab131a7/ github profile: https://github.com/chandrakant100

2 1

[cmake] Problem with dependencies for configure checks
by Andrey Semashev 08 Jun '21

08 Jun '21

Hi, I've been having this problem with CMake in Boost.Filesystem, where I need to have the Boost::library targets available before Boost::filesystem target is defined. This is needed in order to perform configuration checks that will affect how Boost::filesystem will be defined. For example, see the check_cxx_source_compiles calls: https://github.com/boostorg/filesystem/blob/af6ac28b5785820b93a2af7dd6e9b80… For the check_cxx_source_compiles calls, I would have liked to add targets like Boost::config and Boost::winapi to CMAKE_REQUIRED_LIBRARIES so that the checks are compiled with include directories of those dependencies added in the command line. This doesn't work because these targets may not be defined at the point when the configuration checks are performed. My current workaround, as you can see, is to add the Boost root to CMAKE_REQUIRED_INCLUDES, where the boost directory with the common headers tree is located. However, this will not work if we're going to make that directory optional or remove it. Also, you can see that I'm reusing checks implemented in Boost.Config, for which I also had to hard code its relative location from Boost.Filesystem. If we're going to allow different libraries located in separate directory trees, this will also break. My question is, can this be fixed and how? I was wondering if it is possible to make the target generation two-stage, where the first stage identifies library locations, including directories with their headers, and the second stage would define build targets. This way all library directories would be available to the second stage. Although I can already see the problem with second order dependencies with this approach...

5 34