- Boost - lists.boost.org

Re: [boost] Reducing dependency on Boost.Regex
by Robert Ramey 14 Mar '23

14 Mar '23

On 3/13/23 5:54 AM, Boris Kolpackov via Boost wrote: > John Maddock via Boost <boost(a)lists.boost.org> writes: > > This implicit "if you don't include the header then you don't need to > link the dependency" approach doesn't scale well to cases where Boost is > split into individual packages which are managed by a package manager. Right. This is a built-in deficiency of the package manager approach. Dependencies are dependent upon the actual end user application and cannot be logically discerned a priori by any package manager. Contrary to what one would hope, the package manager is not a panacia and trying to make it into one is a hopeless quest which leads to pointless efforts to "eliminate dependencias" and create "standalone" libraries. > When the package manager undertakes to provide a Boost library, it > should come with all the dependencies that could be needed for any > usage scenario, unless certain features are explicitly not enabled > (which is essentially what we have done -- not enabled regex by > default in a bunch of libraries; I suppose we could have instead not > enabled ICU in regex by default). This mini-history illustrates my point above. More thinking is required on this subject. Perhaps the role of the IDE needs to be expanded or ... ? Robert Ramey > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] Reducing dependency on Boost.Regex
by John Maddock 14 Mar '23

14 Mar '23

> There does need to be a way to recognise optional or soft dependencies > though -- a library might include a compatibility header that can > optionally be included if you are also using another library, but this > should not require the other library as a hard dependency. > > If you in turn write a library or app that does use both, then you > depend on both, but they don't depend on each other. > > I think it's ok to put this on the downstream author -- they will try > to build, get a compile error, then add the missing dependency > themselves. > Agreed 100%. The canonical example is serialization: you will most certainly know that you need that library if you intend to serialize and install it anyway, so no need for an automatic dependency. John.

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Gavin Lambert 13 Mar '23

13 Mar '23

On 14/03/2023 01:54, Boris Kolpackov wrote: > This implicit "if you don't include the header then you don't need to > link the dependency" approach doesn't scale well to cases where Boost is > split into individual packages which are managed by a package manager. > When the package manager undertakes to provide a Boost library, it > should come with all the dependencies that could be needed for any > usage scenario, unless certain features are explicitly not enabled > (which is essentially what we have done -- not enabled regex by > default in a bunch of libraries; I suppose we could have instead not > enabled ICU in regex by default). There does need to be a way to recognise optional or soft dependencies though -- a library might include a compatibility header that can optionally be included if you are also using another library, but this should not require the other library as a hard dependency. If you in turn write a library or app that does use both, then you depend on both, but they don't depend on each other. I think it's ok to put this on the downstream author -- they will try to build, get a compile error, then add the missing dependency themselves.

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Francois Kritzinger 13 Mar '23

13 Mar '23

On 2023/03/13 14:07, Andrey Semashev via Boost wrote: > On 3/13/23 15:00, Boris Kolpackov via Boost wrote: >> A quick note on our experience reducing dependency on Boost.Regex >> (and thus ICU) in build2 packages for Boost 1.81.0. Now only the >> following (leaf) libraries unconditionally depend on Boost.Regex: >> >> * Boost.Convert >> * Boost.DLL >> * Boost.Log > > Boost.Log can be configured to use std::regex or Boost.Xpressive as an > alternative to Boost.Regex. However Boost.Log also depends on Boost.Spirit which depends on Boost.Regex so that's a hard dependency.

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Boris Kolpackov 13 Mar '23

13 Mar '23

John Maddock via Boost <boost(a)lists.boost.org> writes: > Can I just point out that regex is now header only, and thus the dependency > is only there if it's actually used, likewise ICU is not required to be > present at build time, but only if boost/regex/icu.hpp is actually used. This implicit "if you don't include the header then you don't need to link the dependency" approach doesn't scale well to cases where Boost is split into individual packages which are managed by a package manager. When the package manager undertakes to provide a Boost library, it should come with all the dependencies that could be needed for any usage scenario, unless certain features are explicitly not enabled (which is essentially what we have done -- not enabled regex by default in a bunch of libraries; I suppose we could have instead not enabled ICU in regex by default).

1 0

Re: [boost] quadmath as distinct library?
by John Maddock 13 Mar '23

13 Mar '23

On 13/03/2023 02:43, Gero Peterhoff via Boost wrote: > Hello, > * problem description > In boost::math::cstdfloat AND boost::multiprecision::float128 > identical functions for __float128 (quadmath) are provided. > > This is unnecessary overhead. I think it would make sense to "pull > out" the quadmath library as a distinct library. I did this once > canonically, but it doesn't work yet because > boost::math::cstdfloat/boost::multiprecision::float128 have to be > adapted for this. This is a prototype where there is still a lot of > work to be done. But the beginning is done. If you mean https://github.com/boostorg/multiprecision/blob/develop/include/boost/multi… then it's a trivially small header, and spinning stuff out into a separate library has a significant maintenance overhead. > > Would it also make sense to "pull out" quaternion and octonion as > distinct libraries? Historically these were separate libraries, and were unmaintained. Moving them under the Boost.Math "umbrella" means that they do at least get minimal maintenance now. Again, splitting stuff out has a non-zero overhead. John.

1 0

Re: [boost] Reducing dependency on Boost.Regex
by John Maddock 13 Mar '23

13 Mar '23

On 13/03/2023 12:00, Boris Kolpackov via Boost wrote: > A quick note on our experience reducing dependency on Boost.Regex > (and thus ICU) in build2 packages for Boost 1.81.0. Can I just point out that regex is now header only, and thus the dependency is only there if it's actually used, likewise ICU is not required to be present at build time, but only if boost/regex/icu.hpp is actually used. [technically, I haven't yet removed the old C++98 code which does have a dependency on ICU, but it will be going very soon]. John.

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Boris Kolpackov 13 Mar '23

13 Mar '23

Andrey Semashev via Boost <boost(a)lists.boost.org> writes: > Boost.Log can be configured to use std::regex or Boost.Xpressive as an > alternative to Boost.Regex. > > https://www.boost.org/doc/libs/1_81_0/libs/log/doc/html/log/installation/co… > > Boost.Regex is the default because it provides the best performance. I'm > not planning to change this. I don't think there would be strong motivation to change this in Log since it's a leaf library (i.e., no other Boost library depends on it). But we can make this configurable in our package if/when there is interest.

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Andrey Semashev 13 Mar '23

13 Mar '23

On 3/13/23 15:00, Boris Kolpackov via Boost wrote: > A quick note on our experience reducing dependency on Boost.Regex > (and thus ICU) in build2 packages for Boost 1.81.0. Now only the > following (leaf) libraries unconditionally depend on Boost.Regex: > > * Boost.Convert > * Boost.DLL > * Boost.Log Boost.Log can be configured to use std::regex or Boost.Xpressive as an alternative to Boost.Regex. https://www.boost.org/doc/libs/1_81_0/libs/log/doc/html/log/installation/co… Boost.Regex is the default because it provides the best performance. I'm not planning to change this.

1 0

Reducing dependency on Boost.Regex
by Boris Kolpackov 13 Mar '23

13 Mar '23

A quick note on our experience reducing dependency on Boost.Regex (and thus ICU) in build2 packages for Boost 1.81.0. Now only the following (leaf) libraries unconditionally depend on Boost.Regex: * Boost.Convert * Boost.DLL * Boost.Log While the following libraries now have an optional (direct or indirect) dependency (follow the link for details on what functionality is now optional and how to enable it): * Boost.Algorithm[1] * Boost.Asio[2] * Boost.Graph[3] * Boost.Iostreams[4] * Boost.Range[5] * Boost.Spirit[6] To achieve this we had to make the following two changes: 1. Make functionality that requires regex optional. This change was made in all the above-mentioned libraries. In all the cases except Boost.Spirit and arguably Boost.Graph, the regex-based functionality was fairly marginal and making it optional feels like a reasonable trade off. 2. Split Boost.Spirit into three logical "components", all optional: classic, v2, and x3. The rationale here is that only the classic component can be reasonably easily made to work without regex. And classic without regex is what's required by Boost.Serialization (we had to deal with Boost.Serialization because it is a dependency of the majority of Boost libraries). We only had to patch Boost.Graph and are working[7] to upstream our changes. Overall, while this required some effort, it's definitely achievable given appropriate tools (mainly support for dependency configuration in the package manager). [1] https://github.com/build2-packaging/boost/blob/master/downstream/libs/algor… [2] https://github.com/build2-packaging/boost/blob/master/downstream/libs/asio/… [3] https://github.com/build2-packaging/boost/blob/master/downstream/libs/graph… [4] https://github.com/build2-packaging/boost/blob/master/downstream/libs/iostr… [5] https://github.com/build2-packaging/boost/blob/master/downstream/libs/range… [6] https://github.com/build2-packaging/boost/blob/master/downstream/libs/spiri… [7] https://github.com/boostorg/graph/issues/326

1 0