2cf352fd8e6a77003e38d954b6c879b20d4b960a doc: document capnproto and libmultiprocess deps (will)
Pull request description:
Closes: #33576
These dependencies are both undocumented, and libmultiprocess has a relatively special requirement in that v6.0 and later are known to not work with v29.x of Bitcoin Core due to https://github.com/bitcoin-core/libmultiprocess/pull/160
ACKs for top commit:
ryanofsky:
Code review ACK 2cf352fd8e6a77003e38d954b6c879b20d4b960a. Thanks for making all these changes and for opening the fix originally.
Tree-SHA512: 3839bb7b0bbb23c3fe358960e93f7919953cac315eaed2b214491dd4f6c80ed500c09a618d11408836bddf6d11fc98b1ca3989f552104c49713ebd8859706ac5
These dependencies are both undocumented, and libmultiprocess has a
relatively special requirement in that v6.0 and later are known to not
work with v29.x of Bitcoin Core due to https://github.com/bitcoin-core/libmultiprocess/pull/160
f25dc84b2892e6bdbbd0471add9fcb2757700981 doc: update release notes for 29.x (Antoine Poinsot)
313023369b8e4ffb268cb642101680fe7f746fea qa: functional test a transaction running into the legacy sigop limit (Antoine Poinsot)
0a4671d5eba2499a27e530536b48b86166319fe8 qa: unit test standardness of inputs packed with legacy sigops (Antoine Poinsot)
204b96591542373dc75c6a6401b477f4b6615e69 policy: make pathological transactions packed with legacy sigops non-standard. (Antoine Poinsot)
Pull request description:
This backports PR #32521 to make the change available to miners who can't (or don't want to) upgrade past version 29.
ACKs for top commit:
marcofleon:
reACK f25dc84b2892e6bdbbd0471add9fcb2757700981
glozow:
ACK f25dc84b2892e6bdbbd0471add9fcb2757700981
Tree-SHA512: d5e06618720ed1a96d8a5fccdd8d1dbcbb5748505aa0df69198326828fe13f220e55bbce813f6f2daae82d23348e1f83a3a20a28639ec3fc2455c5b6e79a56e6
Also, capitalized the comments in build-unix.md for uniformity
with the docs on other targets.
Github-Pull: #32846
Rebased-From: 0e9f409db3b7b08aef75ce39765b018b69cc8e9d
This commit fixes the path listed in the documentation for the fuzz
testing test_runner.py. Previously the --help option worked but running
fuzz tests from the documented path did not.
Github-Pull: #32353
Rebased-From: 61f238e84ac6d24d8f420c2eabcbb2980d7fcb1e
568fcdddaec2cc8decba5a098257f31729cc1caa scripted-diff: Adjust documentation per top-level target output location (Hennadii Stepanov)
026bb226e96919603af829d0b677779a234a0f6e cmake: Set top-level target output locations (Hennadii Stepanov)
Pull request description:
This PR sets the target output locations to the `bin` and `lib` subdirectories within the build tree, creating a directory structure that mirrors that of the installed targets.
This approach is widely adopted by the large projects, such as [LLVM](e146c1867e/lldb/cmake/modules/LLDBStandalone.cmake (L128-L130)):
```cmake
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX})
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX})
```
The `libsecp256k1` project has also recently [adopted](https://github.com/bitcoin-core/secp256k1/pull/1553) this approach.
With this PR, all binaries are conveniently located. For example, run:
```
$ ./build/bin/fuzz
```
instead of:
```
$ ./build/src/test/fuzz/fuzz
```
On Windows, all required DLLs are now located in the same directory as the executables, allowing to run `bitcoin-chainstate.exe` (which loads `bitcoinkernel.dll`) without the need to copy DLLs or modify the `PATH` variable.
The idea was briefly discussed among the build team during the recent CoreDev meeting.
---
**Warning**: This PR changes build locations of newly built executables like `bitcoind` and `test_bitcoin` from `src/` to `bin/` without deleting previously built executables. A clean build is recommended to avoid accidentally running old binaries.
ACKs for top commit:
theStack:
Light re-ACK 568fcdddaec2cc8decba5a098257f31729cc1caa
ryanofsky:
Code review ACK 568fcdddaec2cc8decba5a098257f31729cc1caa. Only change since last review was rebasing. I'm ok with this PR in its current form if other developers are happy with it. I just personally think it is inappropriate to \*silently\* break an everyday developer workflow like `git pull; make bitcoind`. I wouldn't have a problem with this PR if it triggered an explicit error, or if the problem was limited to less common workflows like changing cmake options in an existing build.
TheCharlatan:
Re-ACK 568fcdddaec2cc8decba5a098257f31729cc1caa
theuni:
ACK 568fcdddaec2cc8decba5a098257f31729cc1caa
Tree-SHA512: 1aa5ecd3cd49bd82f1dcc96c8e171d2d19c58aec8dade4bc329df89311f9e50cbf6cf021d004c58a0e1016c375b0fa348ccd52761bcdd179c2d1e61c105e3b9f
