- Boost - lists.boost.org

Re: [boost] [Release] Master branch is closed for beta
by Andrey Semashev 16 Mar '23

16 Mar '23

On 3/9/23 17:19, Marshall Clow via Boost wrote: > Master is closed for all changes. > > See the release schedule at: https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> Is the master branch open now?

1 0

[release] Boost 1.82.0 beta 1 released
by Marshall Clow 15 Mar '23

15 Mar '23

Boost release 1.82.0 beta 1 is now available at: https://boostorg.jfrog.io/artifactory/main/beta/1.82.0.beta1/source/ The SHA256 checksums are: efe17bea3f0b2c11f34828f37d5777f30eb6fef57af355c6a6664b08a4339999 boost_1_82_0_b1.7z 0af2a60f76abb4f411b1bd9c1a553f64454d9414990e8cc12f02f3b431e2ac45 boost_1_82_0_b1.tar.gz 495b2ae2f6970ea1e635f80222d9f6978148496cdd163e87c37cdd6de3b5ccfc boost_1_82_0_b1.zip edf4cb9e8e5a14412b91311438478ef6ce12afe2a54714eb2f0632a454c3d8d5 boost_1_82_0_b1.tar.bz2 Release notes (still need updates): https://www.boost.org/users/history/version_1_82_0.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- Boost Release Team

1 0

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

15 Mar '23

Robert Ramey via Boost <boost(a)lists.boost.org> writes: > On 3/13/23 5:54 AM, Boris Kolpackov via Boost 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. > > 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. They cannot be "magically" discerned but there can be a mechanism for specifying them explicitly. I don't believe we are disagreeing about the fundamental issues, which is that there needs to be support for optional dependencies. The difference is that you seem to advocate implicit discovery (and ongoing maintenance) of optional dependencies by the end-user (based on linker errors, by carefully studying the documentation, etc) while I advocate having an explicit mechanism in the package manager for the library author to specify which functionality is optional (and that requires optional dependencies) and for the library user to request this optional functionality (and automatically get the required dependencies). We have such a mechanism in build2, in our experience it works well, and we have applied it to the Boost libraries. > 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. That's quite a bizarre perspective, seeing that the main functionality of a package manager is to make management of dependencies easier. It also doesn't match empirical evidence. For example, in Rust it's hard to find a package that doesn't have at least a few dozens dependencies (and more often a few hundreds). If anything, the problem is actually the opposite.

1 0

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

15 Mar '23

On 3/15/23 07:04, Gavin Lambert via Boost wrote: > 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. libs/utility/operators.htm exists and redirects to doc/html/utility/utilities/operators.html.

1 1

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