Boost 1.71 or newer is useful for #15382. Unless that PR gets more ACKs, we might as well as wait and see if there’s another Boost release before we branch off 0.20.
In addition, we should keep an eye on the upstream autoconf fix: https://github.com/autoconf-archive/autoconf-archive/pull/198
Opening this draft PR now to deal with any compiler / CI issues.
just upgrade to C++14
There is ongoing discussion on when the right time is to bump c++. It seems the plan is to skip c++14 and go straight to c++17, but it’ll probably be a while: #13356 (comment) and #16684
Getting rid of Boost altogether is not likely to happen anytime soon, see e.g. #8670 (2016!)
Boost 1.71 or newer is useful for #15382.
Release notes for Boost 1.71.0 do not mention any change in Process library (required in #15382) at all. Did I miss something?
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Given that the feature freeze is March 15th and there’s still no new Boost release, 1.72 it is…
Should I update the various boost related autoconf files too (haven’t checked if there’s new ones)?
Concept ~0.
On the one hand, I think bumping a major dependency two versions to fix an unused variable in a module we don’t even use, [“is useful for #15382. “](https://github.com/bitcoin/bitcoin/pull/17941#issue-363685467), is a bit ridiculous. Especially when, if required, it could be fixed quite easily in preprocessing. i.e:
0diff --git a/depends/packages/boost.mk b/depends/packages/boost.mk
1index cd0e70fb1..01b1f9c52 100644
2--- a/depends/packages/boost.mk
3+++ b/depends/packages/boost.mk
4@@ -29,6 +29,7 @@ $(package)_cxxflags_android=-fPIC
5 endef
6
7 define $(package)_preprocess_cmds
8+ sed -i.old "s/int ret_sig = 0;//" boost/process/detail/posix/wait_group.hpp && \
9 echo "using $($(package)_toolset_$(host_os)) : : $($(package)_cxx) : <cxxflags>\"$($(package)_cxxflags) $($(package)_cppflags)\" <linkflags>\"$($(package)_ldflags)\" <archiver>\"$($(package)_archiver_$(host_os))\" <striper>\"$(host_STRIP)\" <ranlib>\"$(host_RANLIB)\" <rc>\"$(host_WINDRES)\" : ;" > user-config.jam
10 endef
On the other, we seem to be be semi-regularly bumping Boost in depends, so maybe we should prior to the 0.20.0 release. I assume you’ve tested this everywhere. Looks like there are a bunch of filesystem changes in 1.72.0. Do we need to do anything in regards to:
On Windows, use Boost.WinAPI to select the target Windows version.
?
Should I update the various boost related autoconf files too
If there’s no applicable bug fixes to any of them, probably not. If there are, and you do update them, please test them across all operating systems and hardware we support so that we don’t end up with another issue like #17010.
I don’t think it’s necessary to include this in 0.20. Let me word it differently: if we want to bump Boost before the next release, then let’s bump to 1.72. But otherwise I’ll just leave this PR open until #15382 comes closer (with your patch as an alternative).
I’ve been testing that PR and stuff built on top of it for a while and haven’t seen any Boost issues, but I haven’t specifically looked for them. Notably I haven’t tested on Windows.
Labels
Build system
Milestone
0.21.0