build: Set AUTHOR_WARNING on warnings #33144

Now that the cmake setting -Werror=dev is set since commit 6a13a6106e3c1ebe95ba6430184d6260a7b942bd for the CI, guix and the dev cmake preset, it could make sense to notify developers about any warnings.

So do that with a single AUTHOR_WARNING.

This can be tested by introducing a bug, like:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 6017775fa7..5610e03c66 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -589,7 +589,7 @@ set(Python3_FIND_FRAMEWORK LAST CACHE STRING "")
 # improves compatibility with Python version managers that use shims.
 set(Python3_FIND_UNVERSIONED_NAMES FIRST CACHE STRING "")
 mark_as_advanced(Python3_FIND_FRAMEWORK Python3_FIND_UNVERSIONED_NAMES)
-find_package(Python3 3.10 COMPONENTS Interpreter)
+find_package(Python3 3.210 COMPONENTS Interpreter)
 if(NOT TARGET Python3::Interpreter)
   list(APPEND configure_warnings
     "Minimum required Python not found."

Fixes #31476.

<!--e57a25ab6845829454e8d69fc972939a-->

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

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33144.

<!--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

No conflicts as of last run.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

Rebased, tested it with:

diff --git a/CMakeLists.txt b/CMakeLists.txt
--- a/CMakeLists.txt	(revision 27e4b8c6856194fa8db028b6f7356f83ea3d7e3a)
+++ b/CMakeLists.txt	(date 1754504896922)
@@ -186,6 +186,7 @@
 string(APPEND CMAKE_CXX_LINK_EXECUTABLE " ${APPEND_LDFLAGS}")

 set(configure_warnings)
+list(APPEND configure_warnings "Testing [#33144](/bitcoin-bitcoin/33144/)")

 include(CheckLinkerSupportsPIE)
 check_linker_supports_pie(configure_warnings)

running:

rm -rfd build && cmake -B build 2>&1 | grep -C1 Warning

Prints before the change:

CMake Warning at CMakeLists.txt:709 (message):
  Testing [#33144](/bitcoin-bitcoin/33144/)

After the change:

CMake Warning at CMakeLists.txt:709 (message):
  Testing [#33144](/bitcoin-bitcoin/33144/)
--

CMake Warning (dev) at CMakeLists.txt:712 (message):
  Warnings have been encountered!
This warning is for project developers.  Use -Wno-dev to suppress it.

ACK fa6497ba71e9573d341c1c051af09b3ec2fc8d74

ACK fa6497ba71e9573d341c1c051af09b3ec2fc8d74

It makes sense to have an option to have configuration warnings dealt as errors, and it's unfortunate that the most elegant way to do that is by somewhat abusing AUTHOR_WARNING, but this seems like the least bad solution to me, until CMake has a -Werror=all option.

I've also been thinking about an alternative approach. configure_warnings is currently used for:

1. missing Python interpreter, which is necessary (without build failure) for the functional test suite, and is necessary (but build will fail) for maintenance and macos deploy targets
2. missing PIE support
3. ccache misconfiguration

For:

1. I think a FATAL_ERROR when functional tests are configured (e.g. f529c145aa0c418618932bf2d730006c7630166f) might be appropriate.
2. it similarly might make sense to trigger a FATAL_ERROR (e.g. c988ca5d41105cea7c72a3ad6ab03c87f2124f26), I'm not sure if we actually want to support compiling without PIE?
3. this might be more controversial, but I don't think WITH_CCACHE should be part of our build system.

Those changes combined would remove configure_warnings entirely, removing the need for this PR, but it obviously is a much bigger change. I've implemented it in https://github.com/bitcoin/bitcoin/compare/7cc9a087069bfcdb79a08ce77eb3a60adf9483af...stickies-v:2025-09/cmake-remove-configure-warnings just to try it out.

Sounds good. Happy to put this in draft for now to see if your removal of configure_warnings makes it in, but I haven't looked at 2. and 3., if they make sense.

Sounds good.

Thanks for the feedback, I've opened #33278.

Happy to put this in draft for now

The changes in this/your PR are small, straightforward, can easily be reverted, and offer immediate practical benefit, so I think it makes sense to not block this on my much less straightforward alternative, so my ACK still stands and I'd be happy if this makes progress.

I don't see how abusing the semantics of AUTHOR_WARNING is preferable to adding our own flag (#31665), but I prefer fixing #31476, so not a big deal.

~I think the changes implemented by @stickies-v in https://github.com/bitcoin/bitcoin/compare/7cc9a087069bfcdb79a08ce77eb3a60adf9483af...stickies-v:2025-09/cmake-remove-configure-warnings make sense individually, but the sum total of this approach is that it shifts the experience of building bitcoin core from cmake -B build doing what it can to configure a reasonable build for you given what it can find to: attempt build, read errors to see what it's mad about, install a dependency or disable a feature, repeat, and that is a much worse experience in my opinion.~

~Trying our best to configure a build and printing warnings and letting mindful users read and address them, and fixing #31476 so that warnings are never tolerated in CI / dev preset builds seems like a better approach to me.~

Edit: On further thought, https://github.com/bitcoin/bitcoin/compare/7cc9a087069bfcdb79a08ce77eb3a60adf9483af...stickies-v:2025-09/cmake-remove-configure-warnings wouldn't really be a shift from the current approach, we don't generally change build configuration based on what is found on the user's system, that was true in the old build system:

https://github.com/bitcoin/bitcoin/blob/44d8b13c81e5276eb610c99f227a4d090cc532f6/build-aux/m4/bitcoin_qt.m4#L5-L17

Edit: Edit:

Also see discussion here: #33290 (comment)

+GHA CI

cc @purpleKarrot

ACK fa6497ba71e9573d341c1c051af09b3ec2fc8d74, this effectively allows us to use -Werror=dev to automatically catch any warning.

ACK fa6497ba71e9573d341c1c051af09b3ec2fc8d74

To be clear: I don't like this. I share @stickies-v opinions on:

1. When functional tests are enabled, Python should be a REQUIRED dependency.
2. (different opinion here)
3. WITH_CCACHE is not project specific.

But I also agree with this one:

The changes in this/your PR are small, straightforward, can easily be reverted, and offer immediate practical benefit, ...

ACK fa6497ba71e9573d341c1c051af09b3ec2fc8d74

Backported to 31.x in #34800.

Can see this working in #34853.

Can see this working in #34853.

I don't think this one is related to this pull request. The changes in this pull request should be rather limited and only affect where we use our own warnings:

• python, pie, and ccache

Generally, if the patch in this pull triggered, it should show a Warnings have been encountered! in the log. The log in 34853 does not contain Warnings have been encountered! and I think the warning there is just a normal author/dev warning, which works as expected out of the box, with or without the changes in this pull request.

Right, these ones are dev warnings, as opposed to author warnings.