Follow-up to #33088.
Adds cmake -B build -LH documentation to Windows build guides, similar to Unix build documentation.
Based on the suggestion and example provided by stickies-v in #33088, with minor adjustment to match existing indented code block format in build-windows.md.
Tested for:
Used to display available configuration options, for consistency with recent changes in Unix build docs
Co-authored-by: stickies-v <stickies-v@users.noreply.github.com>
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33789.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | stickies-v, hebasto, waketraindev, pablomartin4btc |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
ACK 9577daa3b88a8fbe8c96d2848adcc88c55c55a29
ACK 9577daa3b88a8fbe8c96d2848adcc88c55c55a29.
ACK 9577daa
48 | @@ -49,6 +49,9 @@ Build using: 49 | 50 | gmake -C depends HOST=x86_64-w64-mingw32 # Append "-j N" for N parallel jobs. 51 | cmake -B build --toolchain depends/x86_64-w64-mingw32/toolchain.cmake 52 | + 53 | +Run `cmake -B build -LH` to see the full list of available options. 54 | +
nit:
cmake -B build --toolchain depends/x86_64-w64-mingw32/toolchain.cmake
(run `cmake -B build -LH` to see the full list of available options)
I think it needs to match the format in doc/build-unix.md?
Not necessarily, in fact, most build instructions have different structure (unify it, if possible, could be the goal of a different PR, as you can see here we need to copy stuff for every platform). My suggestion is not a blocker just that you are adding this line in the middle of the building instructions, and that's not the case for the other file you are updating. It's an observation, up to you if you want to leave it that way or not.
Thanks for clarifying. I think i'll keep it as-is for now. Yes, unifying structure across build docs as you have suggested is great and can indeed be tackled seperately. Appreciate your feedback!
ACK 9577daa3b88a8fbe8c96d2848adcc88c55c55a29
(please try to avoid mentions/ @-prefixed github names in PR descriptions as it can cause potential issues, primarily related to notification spam)