build: prepare for subtree split #276

We can use a subtree split to export only a subset of this repository to downstream projects. The only thing we need to do is publish and maintain a branch, e.g. lib, generated as follows:

git subtree split --prefix=lib -b lib

I published such a branch here: https://github.com/Sjors/libmultiprocess/commits/lib/

Commits that don't touch the prefix directory are skipped entirely. Others are stripped of content outside the prefix. This of course breaks PGP signatures, but the lib branch commits are deterministically generated. On the Bitcoin Core side I plan to update the subtree linter to verify this.

Because we can only export one directory, this PR moves the following library sources to lib/:

• CMakeLists.txt
• cmake
• include
• pkgconfig
• src
• test

This leaves examples, documentation and CI outside the export. Tests could be moved out as well, but it seems useful to offer downstream projects an easy way to run these tests as part of their own CI.

A new top-level CMakeLists.txt wrapper preserves 'cmake -S .' for standalone builds; this is also the only way to build the example/ subdirectory. See comments in CMakeLists.txt and lib/CMakeLists.txt for details on how lib/ adapts between the two build modes. This can use some CMake expertise eyes. Most of the existing CMakeList.txt content is simply moved, so it's best reviewed with --color-moved=dimmed-zebra.

The second commit can be simplified if we drop examples from cmake/libmultiprocess.cmake in Bitcoin Core in a separate PR first.

Bitcoin Core side: https://github.com/Sjors/bitcoin/pull/113 (will upstream later)

Fixes #232

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #291 (cmake: Add mp_headers custom target by hebasto)
• #288 (Create support branch for CI scripts, documentation, and examples by ryanofsky)
• #287 (Split repository into master (library source) and support (CI, docs, examples) branches. by ryanofsky)
• #285 (Add ReadList helper by ViniciusCestarii)
• #277 (Add std::unordered_set support and a helper BuildList to dedup list build handlers by ViniciusCestarii)
• #274 (Add nonunix platform support by ryanofsky)
• #269 (proxy: add local connection limit to ListenConnections by enirox001)
• #212 (ci: add newdeps job testing newer versions of cmake and capnproto by ryanofsky)
• #209 (cmake: Increase cmake policy version by ryanofsky)
• #204 (cmake: support default build and test workflow by purpleKarrot)
• #175 (Set cmake_minimum_required(VERSION 3.22) by maflcko)
• #163 (build: set cmake policy version to 3.31 by purpleKarrot)

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.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

LLM Linter (✨ experimental)

Possible typos and grammar issues:

• Capn'Proto -> Cap'n Proto [misspelled project name in the comment “Generated C++ Capn'Proto schema files”]

^{2026-06-04 16:27:48}

Concept ACK. It would be great if only needed files were imported into bitcoin core and things like ci scripts, documentation, and examples were excluded, since this could speed up review in both repositories.

The approach here also seems workable although I think I'd probably still prefer the idea of moving unneeded files to a support branch as described #232 (comment) instead of using a partial subtree. That approach seems nice because it wouldn't require any changes to subtree import steps, or to the verifier, and wouldn't impact hashes, and wouldn't require any files except the support files to move. I also like the property of that approach where individual PRs only update the support branch or master branch, changes to master can't sneak in a support PR, and review effort can be focused on the right places (relatively more scrunity on master branch, and more freedom to experiment with CI improvements on the support branch).

<!--cf906140f33d8803c4a75a2196329ecb-->

🐙 This pull request conflicts with the target branch and needs rebase.

Closing in favor of the approach in #287.