Guard manpage generation by reading CMakeCache.txt and exiting if HAVE_SYSTEM, ENABLE_WALLET, or WITH_ZMQ are off, and provide a short hint so contributors rebuild with the right flags instead of committing incomplete manpages.
Fixes #17506
Override by exporting SKIP_BUILD_OPTIONS_CHECK=1 if you really need a custom-fit manpage (see bitcoin/bitcoin#29457 (comment)).
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33828.
See the guideline for information on the review process. A summary of reviews will appear here.
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.
Thanks for taking a look, fanquake.
I noticed #33085 had gone quiet for a little over three weeks with the review concerns still open, so I put this together.
In #33085 the script pulls component flags from test/config.ini (adding checks for CLI, chainstate, fuzz, USDT tracepoints, etc.), but that file only exists when tests are configured and most of those toggles don’t affect the manpages. This branch reads CMakeCache.txt, the authoritative record of the configuration, and only verifies the interfaces that actually change the generated help text.
#33085 adds a new --skip-build-options-check flag, whereas this keeps using the existing SKIP_BUILD_OPTIONS_CHECK environment override so the command-line surface stays the same. The error messaging here points directly at the missing CMake options and explains how to bypass the guard, which lines up with the release-process docs, and the helper functions make the new logic reusable instead of nesting more ad-hoc parsing in the main flow.
I appreciate the work Brandon already put in to #33085 and I looked his code over thoroughly before tackling this, but I thought this solution was more elegant and would be preferred. Wanting to follow proper etiquette, perhaps I should have commented my suggestions on his PR instead of opening my own?
This duplicates #33085. If the author doesn’t follow up there shortly, we could reopen here.
It’s been a few weeks, would it be appropriate to reopen here? I did try to reach out to @BrandonOdiwuor on the comments of #33085 and haven’t heard back from him yet.