mirrors/bitcoin
1
0
Fork 0
mirror of https://github.com/bitcoin/bitcoin.git synced 2025-03-13 19:37:04 +01:00
Code Issues Projects Releases Wiki Activity
bitcoin/contrib
History
merge-script 502d47203e
Merge bitcoin/bitcoin#31161: cmake: Set top-level target output locations 
568fcdddae scripted-diff: Adjust documentation per top-level target output location (Hennadii Stepanov)
026bb226e9 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 568fcdddae
  ryanofsky:
    Code review ACK 568fcdddae. 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 568fcdddae
  theuni:
    ACK 568fcdddae

Tree-SHA512: 1aa5ecd3cd49bd82f1dcc96c8e171d2d19c58aec8dade4bc329df89311f9e50cbf6cf021d004c58a0e1016c375b0fa348ccd52761bcdd179c2d1e61c105e3b9f
2025-03-12 11:19:00 +08:00
..
asmap Compare ASMaps with respect to specific addresses 2024-06-27 16:35:15 +02:00
completions testnet: Introduce Testnet4 2024-08-06 01:38:10 +02:00
debian doc: upgrade license to 2025. 2025-01-06 12:23:11 +00:00
devtools Merge bitcoin/bitcoin#31161: cmake: Set top-level target output locations 2025-03-12 11:19:00 +08:00
guix Docs: fix typos in documentation files 2025-03-08 09:26:18 +08:00
init security: restrict abis in bitcoind.service 2023-08-24 16:54:47 -04:00
linearize contrib: support reading XORed blocks in linearize-data.py script 2024-08-07 23:53:39 +02:00
macdeploy contrib: Sign and notarize all MacOS binaries 2025-02-19 08:38:22 -08:00
message-capture test: use built-in collection types for type hints (Python 3.9 / PEP 585) 2023-10-25 01:10:21 +02:00
qos scripted-diff: Bump copyright headers 2021-12-30 19:36:57 +02:00
seeds seeds: update .gitignore with signet and testnet4 2025-03-06 15:39:58 -06:00
shell guix: Add source-able bash prelude and utils 2021-04-05 11:00:21 -04:00
signet scripted-diff: Adjust documentation per top-level target output location 2025-02-20 22:18:57 +00:00
testgen contrib: make gen_key_io_test_vectors deterministic 2022-04-06 17:02:50 +02:00
tracing Merge bitcoin/bitcoin#31161: cmake: Set top-level target output locations 2025-03-12 11:19:00 +08:00
utxo-tools contrib: fix read metadata related comment 2025-02-21 16:55:30 +05:30
verify-binaries contrib: Fixup verify-binaries OS platform parsing 2024-06-25 11:32:56 -05:00
verify-commits add ryanofsky to trusted-keys 2023-05-08 23:30:56 -04:00
windeploy contrib: Sign all Windows binaries too 2025-02-19 08:38:22 -08:00
zmq scripted-diff: Bump copyright headers 2021-12-30 19:36:57 +02:00
filter-lcov.py scripted-diff: Bump copyright headers 2020-12-31 09:45:41 +01:00
README.md contrib: add tool to convert compact-serialized UTXO set to SQLite database 2024-12-28 02:38:57 +01:00
valgrind.supp scripted-diff: Adjust documentation per top-level target output location 2025-02-20 22:18:57 +00:00

README.md

Repository Tools

Developer tools

Specific tools for developers working on this repository. Additional tools, including the github-merge.py script, are available in the maintainer-tools repository.

Verify-Commits

Tool to verify that every merge commit was signed by a developer using the github-merge.py script.

Linearize

Construct a linear, no-fork, best version of the blockchain.

Qos

A Linux bash script that will set up traffic control (tc) to limit the outgoing bandwidth for connections to the Bitcoin network. This means one can have an always-on bitcoind instance running, and another local bitcoind/bitcoin-qt instance which connects to this node and receives blocks from it.

Seeds

Utility to generate the pnSeed[] array that is compiled into the client.

Build Tools and Keys

Packaging

The Debian subfolder contains the copyright file.

All other packaging related files can be found in the bitcoin-core/packaging repository.

MacDeploy

Scripts and notes for Mac builds.

Test and Verify Tools

TestGen

Utilities to generate test vectors for the data-driven Bitcoin tests.

Verify-Binaries

This script attempts to download and verify the signature file SHA256SUMS.asc from bitcoin.org.

Command Line Tools

Completions

Shell completions for bash and fish.

UTXO Set Tools

UTXO-to-SQLite

This script converts a compact-serialized UTXO set (as generated by Bitcoin Core with dumptxoutset) to a SQLite3 database. For more details like e.g. the created table name and schema, refer to the module docstring on top of the script, which is also contained in the command's --help output.