-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmake: Add external signer support #79
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK 3371f3d
ff2f574
to
dacc6f7
Compare
3371f3d
to
067bb25
Compare
Rebased. |
How is the first one fixed? I'm guessing it's because these checks are no-longer being run with same warning flags? I assume the second one is because -pthread is now just always being passed or something? |
8a05399
to
dd11216
Compare
Thanks! Fixed. |
Not so simple :) I tried to reproduce the initial issue, which was fixed in bitcoin#24397, using for testing the 077cfff commit and commands as follows: make -C depends -j $(nproc) NO_QT=1 NO_WALLET=1 NO_ZMQ=1 NO_UPNP=1 NO_NATPMP=1 NO_USDT=1 CC=gcc-10 CXX=g++-10
./autogen.sh && ./configure CONFIG_SITE=$PWD/depends/x86_64-pc-linux-gnu/share/config.site --enable-external-signer
config.log:
FWIW, reading libc release notes did not give a clue. |
I would guess that's because recent versions of libc now include pthread, so pthread linking is no-longer required. I don't understand how this branch can drop the workaround in other cases, unless pthread is being linked some other way. |
It's in the 2.34 release notes: https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html
|
dd11216
to
adc9c84
Compare
Addressed @fanquake's comments. Add more CI jobs for Boost.Process edge cases. |
cmake/module/AddBoostIfNeeded.cmake
Outdated
set(CMAKE_REQUIRED_FLAGS "${working_compiler_werror_flag}") | ||
# Boost 1.78 requires the following workaround. | ||
# See: https://github.com/boostorg/process/issues/235 | ||
string(APPEND CMAKE_REQUIRED_FLAGS " -Wno-error=narrowing") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By default, CMake treats
include directories from the interfaces of consumed Imported Targets as system directories.
That means that we have --enable-suppress-external-warnings
behaviour for granted.
If we won't bother to mirror the opposite behaviour, these 4 lines might be dropped.
PR description needs updating? |
Sure. Updated. |
17f4870
to
6367599
Compare
adc9c84
to
d361e3a
Compare
Rebased. |
d361e3a
to
2e86eda
Compare
cmake/module/AddBoostIfNeeded.cmake
Outdated
if(WITH_EXTERNAL_SIGNER) | ||
include(CheckCXXSourceCompiles) | ||
set(CMAKE_REQUIRED_INCLUDES ${Boost_INCLUDE_DIR}) | ||
set(CMAKE_REQUIRED_FLAGS "${working_compiler_werror_flag}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we actually want this on, do we? What if some future boost version has a non-fatal warning? Don't we only want the Wno-error
in case a user has turned on Werror
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it does not correlate with the master branch (and I don't recall why I added it).
This line has been removed in the recent push to mirror the master branch behavior.
Looks good to me other than the outstanding comments:
|
2e86eda
to
aa53fe3
Compare
Thanks for review!
Updated per feedback. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tACK aa53fe3
Optional packages:
GUI ................................. Qt5
external signer ..................... ON
NAT-PMP ............................. ON
UPnP ................................ ON
ZeroMQ .............................. ON
USDT tracing ........................ ON
Tested it quickly running rpc enumeratesigners
successfully (doen't work without the external signer feature enabled returning Method not found
).
./build/src/bitcoin-cli -signet -datadir=$HEBASTO_DATADIR enumeratesigners
error code: -1
error message:
Error: restart bitcoind with -signer=<cmd>
More tests for Boost.Process edge cases.
ACK 617ef5b Copied @pablomartin4btc trick for checking if signer support is available. With ➜ build git:(240118-cmake-AY) ./src/bitcoin-cli -regtest -datadir=/tmp/bitcoinddata enumeratesigners
error code: -32601
error message:
Method not found With ➜ build git:(240118-cmake-AY) ./src/bitcoin-cli -regtest -datadir=/tmp/bitcoinddata enumeratesigners
error code: -1
error message:
Error: restart bitcoind with -signer=<cmd> Just as an aside, when I set external signer to "on" lowercase the print out after configure is: |
" HAVE_BOOST_PROCESS | ||
) | ||
if(HAVE_BOOST_PROCESS) | ||
if(WIN32) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: if it's WIN32 couldn't you just return early with external signer OFF and not bother checking if boost supports boost process? Would cleanup one nested if.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right. However, I've chosen this clumsy approach to mimic the Autotools' one for the sake of easier reviewing,
Anyway, this code will be gone after bitcoin#28981.
That is a flaw in tri-state option implementation. Anyway, it will be gone before merging into the master branch; see #83. |
@pablomartin4btc indeed, though after bitcoin#28981 bringing back Windows should be doable. |
A new configuration option is
WITH_EXTERNAL_SIGNER
.