- Boost - lists.boost.org

Do we still want develop branch?
by Andrey Semashev 16 Nov '23

16 Nov '23

Hi, The recent case of a commit in develop that was left unmerged to master made me wondering if people still find the develop branch useful. Historically (since the SVN days), we used a separate branch for active development, which we then merged to the stable branch that was used for creating Boost releases. This allowed to test libraries together before changes propagate to the stable branch. This was useful back when the official test matrix was the primary gauge of the Boost "health", so when something broke, it was rather visible, even if the breakage manifested in downstream libraries. With the adoption of git and CI, the relevance of the test matrix has diminished, and, presumably, people have shifted towards monitoring their libraries' CI. Which means, people are less likely to notice that something broke downstream, unless the downstream developer notices and reports the problem. Although I have been that downstream developer myself quite a few times, I have to admit that this role of the develop branch of "an integration testing field" is not well filled in the current workflow. Noticing the breakage is mostly luck (i.e. a matter of me making a commit to my library and noticing the CI failure caused by an upstream dependency) rather than a rule. Additionally, I have been asked on a few occasions to avoid development directly in the develop branch and use separate feature branches instead. That is, do your commits in a feature branch, let the CI pass, then merge to develop, let the CI pass again, then merge to master. Apparently, some people are using this workflow by default to avoid breakage in develop, which means develop is no longer the branch where the actual development happens. (This workflow actually makes develop meaningless because your CI over the feature branch already tests your changes against develop of the rest of Boost. Which means after merging to develop you're running the same CI again, and might as well just merge to master straight away.) Then there's the recurring problem that led to this post - people forget to merge to master from time to time. Or simply don't have time to merge. Or the library is no longer actively maintained. Or the commit is left out of master for any other reason, which means users don't receive their bug fixes in a release. Personally, I do try to remember the PRs I make during the release cycle and look through them just before the release to make sure they are merged to master. Some of you probably received gentle merge reminders from me. I'm not sure if anyone else is doing this, but I can say this is an active mental effort on my part, which I'd rather not have to make. And even then I can't be sure I remember all PRs or have the time to cycle though them before the release. Which brings me to my question. Do people still find the develop branch useful? Maybe we'd be better off just dropping it and performing all development in feature branches before merging straight to master? Also, if you do find develop useful, what do you think about creating a GitHub Action to automatically merge develop to master once the CI on develop succeeds? Maybe there are other ideas how to avoid commits unmerged to master? Thanks.

8 51

Re: [boost] Do we still want develop branch?
by Jonathan Wakely 13 Nov '23

13 Nov '23

Oops, resending from the address that is actually sub'd the the list ... On Mon, 6 Nov 2023 at 19:13, Jonathan Wakely wrote: > > > On Mon, 6 Nov 2023 at 16:45, Robert Ramey via Boost <boost(a)lists.boost.org> > wrote: > >> On 11/6/23 1:45 AM, Alexander Grund via Boost wrote: >> > I agree here that this is a major issue and maybe the release managers >> > can check (e.g. with Peters script) for that common issue and maybe >> even >> > initiate merges. >> >> Seems to me it would be easy to make a script which the release manager >> would run before release which would flag all libraries which have >> unmerged changes on the development branch dated before the current >> date. This might resolve the whole issue. >> >> > That would imply a rule of thumb that develop should (in general) have no > changes that aren't merged to master ready for a release. > > If you're going to have such a rule, you might as well just get rid of the > two branch model and just use a trunk-based git workflow. So you work on > develop, and then at some point you create a release branch from develop, > call it boost_1_84_0 and that release branch is used for the release. No > manual merging from develop to master, because the release branch comes > straight from develop, not from an unrelated branch which should (in > theory, if the maintainer remembers) match the *content* of develop, but > not the actual history of develop. > > > > https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-… > https://www.toptal.com/software/trunk-based-development-git-flow > https://trunkbaseddevelopment.com/ > >

7 14

[Release] Master branch is closed for beta
by Marshall Clow 09 Nov '23

09 Nov '23

Master is closed for all changes. See the release schedule at: https://www.boost.org/development/index.html -- Release managers

1 0

Re: [boost] [boost.cobalt] A precondition or an error condition?
by Andrzej Krzemienski 09 Nov '23

09 Nov '23

czw., 9 lis 2023 o 17:32 Klemens Morgenstern < klemensdavidmorgenstern(a)gmail.com> napisał(a): > > Actually, your explanation convinces me even stronger that this should > be a different function with a different name. It is a different use case, > it has a different signature, a different return type. > > > > How is the use case different? I got multiple awaitable and I want to > wait for one to finish. The decision of how many is either a runtime > or a compile time decision and we're discussing how to handle the > runtime error. Sounds like the same thing to me. > They have different preconditions: one requires a non-epty variadic pack. One allows promises with different result types, the other doesn't. They differ in return types: one returns a variant, the other returns a pair. So, the following code will look different in either case. Sure they share some similarities. Much like `race` and `left_race` do. But they have two different names. Regards, &rzej;

1 0

[boost.cobalt] A precondition or an error condition?
by Andrzej Krzemienski 09 Nov '23

09 Nov '23

Hi Everyone, I would like to discuss one correctness aspect of Boost.COBALT. We have this list and the Slack channel, so I am not sure which place is better. Let me do it here. In Boost.Cobalt (formerly Boost.Async) we have function cobalt::race (formerly select()) that takes a range of awaitables `p` and returns an awaitable capable on awaiting on one of the elements of `p`: https://www.boost.org/doc/libs/develop/libs/cobalt/doc/html/index.html#race… Example: ``` promise<string> talk_to_server_1(); promise<string> talk_to_server_2(); promise<string> timeout_with_default(); vector<promise<int>> servers = { talk_to_server_1(), talk_to_server_2(), timeout_with_default() }; pair<size_t, string> ans = co_await race(servers); ``` This obviously cannot work when the input range passed to `race` is empty. Boost.COBALT docs say that for this situation "Selecting an empty range will cause an exception to be thrown". But I do not think it is the right approach. The right approach would be to clearly communicate to the user of the library that this is an incorrect usage of the library: if you pass an empty range to `race` you clearly do not know what you are doing, or you simply overlooked it and planted a bug. The library should list it as a *precondition* in the docs: the passed range cannot be empty. If you do it, you cannot expect your program to work correctly. >From the perspective of the library author, you can now, for the event of passing the empty range, putt all the tools that help in debugging: * BOOST_ASSERT * insert a breakpoint And on the next line, you can also throw an exception to avoid an UB. But in that case the exception would not be part of the official contract. If the docs just say "throws an exception" (as today, which I think is wrong) then the library author is not allowed to insert any debugging aids (such as BOOST_ASSERT or breaking into the debugger) because the user may be relying on the exception throw. You do not want the users to rely on the exception throw: you want to prevent the users from passing the empty range. What do others think about it? Regards, &rzej;

3 6

[release] Master branch closes for the 1.84.0 beta release TOMORROW
by Marshall Clow 08 Nov '23

08 Nov '23

Calendar here: https://www.boost.org/development/ — The release managers

3 5

Linking Problems starting with Boost 1.81
by Dennis Luehring 05 Nov '23

05 Nov '23

1.79 links with my software 1.80 links with my software 1.81 does not link 1.82 does not link 1.83 does not link Linux up to date Suse/Tumbleweed gcc 13.2.1 ./bootstrap.sh ./b2 -j16 --toolset=gcc cxxflags=-fPIC --build-dir=./_build address-model=64 architecture=x86 threading=multi --stagedir=./lib64-gcc --build-type=complete --layout=versioned --without-mpi these are the errors on linking when using 1.81 and above ld.lld: error: duplicate symbol: boost::phoenix::placeholders::uarg1 >>> defined at local_256.hpp:16 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:16) >>> Recipe_expression_validator.cpp.o:(boost::phoenix::placeholders::uarg1) in archive ../../implementation/expression_validation/libexpression_validation.a >>> defined at local_256.hpp:16 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:16) >>> parser.cpp.o:(.bss+0xF80) in archive ../../devs/expression_parser_lib/libexpression_parser_lib.a ld.lld: error: duplicate symbol: boost::phoenix::placeholders::uarg2 >>> defined at local_256.hpp:19 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:19) >>> Recipe_expression_validator.cpp.o:(boost::phoenix::placeholders::uarg2) in archive ../../implementation/expression_validation/libexpression_validation.a >>> defined at local_256.hpp:19 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:19) >>> parser.cpp.o:(.bss+0xFC0) in archive ../../devs/expression_parser_lib/libexpression_parser_lib.a ld.lld: error: duplicate symbol: boost::phoenix::placeholders::uarg3 >>> defined at local_256.hpp:22 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:22) >>> Recipe_expression_validator.cpp.o:(boost::phoenix::placeholders::uarg3) in archive ../../implementation/expression_validation/libexpression_validation.a >>> defined at local_256.hpp:22 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:22) >>> parser.cpp.o:(.bss+0x1000) in archive ../../devs/expression_parser_lib/libexpression_parser_lib.a anyone got an idea what changed between 1.80 and 1.81 to let my linking fail with the above errors the expression_parser_lib and expression_validation is my own code

4 8

Reminder: Boost 1.84.0 release cycle starting
by Marshall Clow 04 Nov '23

04 Nov '23

The deadline for “major changes” is next Wednesday, 1-Nov. The beta release will be two weeks later. As always, the release calendar is at: https://www.boost.org/development/index.html — Marshall

5 5

Boost test matrix
by Robert Ramey 04 Nov '23

04 Nov '23

I've merged my develop branch into the the master, waited some time, and reviewed the test results here: https://www.boost.org/development/tests/develop/developer/serialization.html . Given that we intend to release soon, I have a few questions: a) I don't see any windows compilers here. WTF? b) If I switch to "Release View" (upper left hand corner) I expect to see test runs for the master branch. I just get an error message. I can't see how we can think of doing a release with having these issues resolved. Robert Ramey

6 8

error on inclusion of ../boost/math/special_functions/next.hpp
by Robert Ramey 03 Nov '23

03 Nov '23

In reviewing the test matrix: https://www.boost.org/development/tests/develop/developer/serialization.html I'm getting the following error message when on a couple of my tests: > Test output: teeks99-dkr-dc6-17 - serialization - test_complex_text_archive / clang-linux-6.0~c++17 > Rev 1c12b5c15fc82f0cb6d4bd931a057fc050df8a34 / Sun, 29 Oct 2023 21:39:02 +0000 > Compile [2023-10-29 23:34:25 UTC]: fail > > > "clang++-6.0" -fvisibility-inlines-hidden -Wno-c99-extensions -std=c++17 -fPIC -m64 -pthread -O0 -fno-inline -Wall -fvisibility=hidden --target=x86_64-pc-linux -ftemplate-depth-255 -DBOOST_ALL_NO_LIB=1 -DBOOST_ARCHIVE_TEST=text_archive.hpp -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_BEAST_ALLOW_DEPRECATED -DBOOST_BEAST_SEPARATE_COMPILATION -DBOOST_COBALT_USE_STD_PMR=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LIB_DIAGNOSTIC=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DBOOST_WSERIALIZATION_DYN_LINK=1 -I".." -c -o "/var/boost/run/results/boost/bin.v2/libs/serialization/test/test_complex_text_archive.test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/test_complex.o" "../libs/serialization/test/test_complex.cpp" > > In file included from ../libs/serialization/test/test_complex.cpp:19: > In file included from ../boost/math/special_functions/next.hpp:17: > In file included from ../boost/math/special_functions/trunc.hpp:21: > In file included from ../boost/math/ccmath/ldexp.hpp:15: > In file included from ../boost/math/ccmath/abs.hpp:16: > ../boost/math/ccmath/isnan.hpp:35:29: error: no template named 'is_integral_v' in namespace 'std'; did you mean 'is_integral'? > if constexpr (!std::is_integral_v<T>) > ~~~~~^~~~~~~~~~~~~ > is_integral > /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/type_traits:289:12: note: 'is_integral' declared here > struct is_integral > ^ Looks like a minor snafu in ../boost/math/ccmath/isnan.hpp ... or not. Could someone who understands math/special functions took a look into this? On a totally separate note: I'm getting another failure on the same matrix: Test output: teeks99-dkr-dc6-17 - serialization - test_dll_simple / clang-linux-6.0~c++17 Rev 1c12b5c15fc82f0cb6d4bd931a057fc050df8a34 / Sun, 29 Oct 2023 21:39:02 +0000 Lib [2023-10-29 23:34:28 UTC]: fail See boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden where the links points to a file containing: > Test output: boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden > Rev 1c12b5c15fc82f0cb6d4bd931a057fc050df8a34 / Sun, 29 Oct 2023 21:39:02 +0000 > Compile [2023-10-29 23:34:25 UTC]: succeed > > "clang++-6.0" -fvisibility-inlines-hidden -Wno-c99-extensions -std=c++17 -fPIC -m64 -pthread -O0 -fno-inline -Wall -fvisibility=hidden --target=x86_64-pc-linux -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_BEAST_ALLOW_DEPRECATED -DBOOST_BEAST_SEPARATE_COMPILATION -DBOOST_COBALT_USE_STD_PMR=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -I".." -c -o "/var/boost/run/results/boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/dll_polymorphic_derived2.o" "../libs/serialization/test/dll_polymorphic_derived2.cpp" > > In file included from ../libs/serialization/test/dll_polymorphic_derived2.cpp:13: > In file included from ../libs/serialization/test/polymorphic_derived2.cpp:15: > ../libs/serialization/test/polymorphic_base.hpp:29:13: warning: polymorphic_base imported [-W#pragma-messages] > #pragma message ("polymorphic_base imported") > ^ > In file included from ../libs/serialization/test/dll_polymorphic_derived2.cpp:13: > In file included from ../libs/serialization/test/polymorphic_derived2.cpp:16: > ../libs/serialization/test/polymorphic_derived2.hpp:32:13: warning: polymorphic_derived2 exported [-W#pragma-messages] > #pragma message ("polymorphic_derived2 exported") > ^ > 2 warnings generated. > > Link [2023-10-29 23:34:25 UTC]: succeed > > > "clang++-6.0" -o "/var/boost/run/results/boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/libdll_polymorphic_derived2.so.1.84.0" -Wl,-soname -Wl,"libdll_polymorphic_derived2.so.1.84.0" -shared -Wl,--start-group "/var/boost/run/results/boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/dll_polymorphic_derived2.o" "/var/boost/run/results/boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/libdll_polymorphic_base.so.1.84.0" "/var/boost/run/results/boost/bin.v2/libs/serialization/build/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/libboost_serialization.so.1.84.0" "/var/boost/run/results/boost/bin.v2/libs/filesystem/build/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/libboost_filesystem.so.1.84.0" -Wl,-Bstatic -Wl,-Bdynamic -lrt -Wl,--end-group -fPIC -m64 -pthread -fvisibility=hidden -fvisibility-inlines-hidden --target=x86_64-pc-linux So .... This parts builds a dll/shared library which is used in the test. There doesn't seem to be anything wrong with this. Does anyone have any ideas? Robert Ramey

3 3