- Boost - lists.preview.boost.org

Re: [boost] v1.81.0 web page: operators library links to utility
by Gavin Lambert 15 Mar '23

15 Mar '23

On 15/03/2023 16:33, Brook Milligan wrote: > I’m not sure who to report this to, but it seems to me that on the > web page for Boost v1.81.0 docs, the Operators library link is to > Utility not Operators. Boost.Operators isn't actually a real library; it's part of Boost.Utility. But it does have the wrong link. For reference: - Page: https://www.boost.org/doc/libs/1_81_0/ - Link target: https://www.boost.org/doc/libs/1_81_0/libs/utility/operators.htm - Actual page: https://www.boost.org/doc/libs/1_81_0/libs/utility/doc/html/utility/utiliti… It looks like this broke as of Boost 1.78.

1 0

v1.81.0 web page: operators library links to utility
by Brook Milligan 15 Mar '23

15 Mar '23

I’m not sure who to report this to, but it seems to me that on the web page for Boost v1.81.0 docs, the Operators library link is to Utility not Operators. Cheers, Brook

1 0

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

15 Mar '23

On 15/03/2023 06:35, Robert Ramey wrote: > 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. What I imagine is part of the problem is that the package management ecosystem has grown up independently from the component authors -- so the package maintainer runs tools to see "oh, this header file is included, that must be a dependency" because they're less familiar with the *context* of that inclusion than the actual component author, and there aren't even standardized package names let alone a standardized way for the component author to indicate to package tools what things should be considered required vs. optional. There are occasional whispers of something almost like that, in the form of autoconf, pkg-config, or CMakeFiles that can list dependencies, but these aren't universal and can have complex logic based on options. And then there's distinctions between dev and runtime dependencies...

1 0

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