build: define CMAKE_COMPILE_WARNING_AS_ERROR as a cache option #34605

1. 
   willcl-ark commented at 12:28 pm on February 17, 2026: member

   CMAKE_COMPILE_WARNING_AS_ERROR is not a cache variable by default in CMake, so it has no value in the configure summary when not set, and even when set cannot be toggled in ccmake. Define it as an option() to make it a cache BOOL with a default of OFF.

   From the original MR to cmake, this was deliberately not set as a cache variable: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7187 (see Brad King’s reply to the collapsed comments from Marc Chevrier).

   Most CMAKE_* variables which are expected to be toggled by users are (as far as I can research) cache variables by default. Those that are considered likely to be set by the project (e.g. CMAKE_CXX_STANDARD or CMAKE_POSITION_INDEPENDENT_CODE) are not, along with read-only variables, script/internal variables, platform sppecific variables, template variables. CMAKE_COMPILE_WARNING_AS_ERROR may be a slight outlier here.

   I count ~ 600 documented CMAKE_* variables, of which ~ 60 are default cache variables.

   I could only see a few of these like:

   • CMAKE_COMPILE_WARNING_AS_ERROR
   • CMAKE_CXX_STANDARD,
   • CMAKE_POSITION_INDEPENDENT_CODE
   • CMAKE_INTERPROCEDURAL_OPTIMIZATION

   …that we (or any project) might want to expose as user-togglable, and would have to add as an option() in CMakeLists.txt.

2. DrahtBot added the label Build system on Feb 17, 2026
3. 
   DrahtBot commented at 12:28 pm on February 17, 2026: contributor

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

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

   Conflicts

   Reviewers, this pull request conflicts with the following ones:

   • #33974 (cmake: Check dependencies after build option interaction by hebasto)

   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.

4. build: define CMAKE_COMPILE_WARNING_AS_ERROR as a cache option

   CMAKE_COMPILE_WARNING_AS_ERROR is not a cache variable by default in
   CMake, so it has no value in the configure summary when not set, and
   even when set cannot be toggled in ccmake. Define it as an option() to
   make it a cache BOOL with a default of OFF.

   231dd04b8d
5. willcl-ark force-pushed on Feb 17, 2026
6. DrahtBot added the label CI failed on Feb 17, 2026
7. DrahtBot removed the label CI failed on Feb 17, 2026
8. 
   willcl-ark commented at 1:38 pm on February 17, 2026: member

   Comment from MR for easier visibility:

9. 
   hebasto commented at 3:06 pm on February 17, 2026: member

   cc @purpleKarrot
10. 
    purpleKarrot commented at 4:58 pm on February 17, 2026: contributor

    I have mixed feelings about this. Generally, my position is that projects should not set any CMAKE_ variables at all and instead respect that those variables may be set from the outside by the builder/packager, via command line or environment.

    However, CMAKE_COMPILE_WARNING_AS_ERROR does not really fit in the usual pattern. It is not initialized by an environment variable, but instead CMake supports the --compile-no-warning-as-error option to allow builders/packagers to ignore the setting made by the project (See also my comment here).

    So I might actually be persuaded to agree that we unconditionally set CMAKE_COMPILE_WARNING_AS_ERROR (or preferably the COMPILE_WARNING_AS_ERROR target property explicitly on select targets). This would still allow clients to turn off the setting via the aforementioned command line flag.

11. 
    willcl-ark commented at 9:06 pm on February 17, 2026: member

    Thanks for your thoughts @purpleKarrot, some of my own after playing with these approaches further:

    So I might actually be persuaded to agree that we unconditionally set CMAKE_COMPILE_WARNING_AS_ERROR (or preferably the COMPILE_WARNING_AS_ERROR target property explicitly on select targets). This would still allow clients to turn off the setting via the aforementioned command line flag.

    I think that if we do either of “unconditionally set CMAKE_COMPILE_WARNING_AS_ERROR (or preferably the COMPILE_WARNING_AS_ERROR target property explicitly on select targets)”, the side-effects are:

    1. our configure output may be innaccurate (Treat compiler warnings as errors ..... ON when it’s disabled via --compile-no-warning-as-error), maybe we drop this?
    2. we will not be able to modify the setting on-the-fly with ccmake, perhaps not particularly important, but it did partly motivate this PR.
    3. In the case of an unconditional set, this would shadow any user passed flag (so cmake -B build -DCMAKE_COMPILE_WARNING_AS_ERROR=OFF woudl not work as expected), although we could use a guard here if we wanted this fixed.

    As I see it, setting as a cache variable feels quite elegant, vs those tradeoffs…

    Am I correct in thinking that you would prefer to set it per-target to i) be maximally modular and ii) avoid setting it on third-party vendored code? Or is there another reason?

12. 
    maflcko commented at 9:29 pm on February 17, 2026: member

    I don’t think CMAKE_COMPILE_WARNING_AS_ERROR should be enabled by default. There doesn’t exist a single version of gcc that can compile Bitcoin Core without false positive warnings, so turning it on by default has questionable benefits among making it impossible to compile Bitcoin Core for users that are not familiar with the cmake knobs.

    • #27343#event-22092375856
    • #29359
13. 
    purpleKarrot commented at 10:34 pm on February 17, 2026: contributor

    @willcl-ark, I said “I might be persuaded to agree”. But if you are in doubt, I will stick to my position.

Contributors
willcl-ark DrahtBot hebasto purpleKarrot maflcko

Labels
Build system