cmake: Check user-defined `APPEND_*FLAGS` variables early

hebasto commented at 4:35 pm on April 28, 2025: member

For the purpose of checks performed by the build system, we strive to handle user-defined APPEND_*FLAGS in the same way as flags provided by other standard means. In particular, they are considered when the try_compile() command is used.

However, these flags are not considered during enable_language() command invocation due to design limitations, which might cause issues, such as #32323.

This PR addresses the issue by introducing an additional compiler check that does consider the user-defined APPEND_*FLAGS.

Fixes #32323:

 0$ cmake -B build -DAPPEND_CXXFLAGS="-ftrivial-auto-var-init"
 1-- The CXX compiler identification is GNU 14.2.0
 2-- Detecting CXX compiler ABI info
 3-- Detecting CXX compiler ABI info - done
 4-- Check for working CXX compiler: /usr/bin/c++ - skipped
 5-- Detecting CXX compile features
 6-- Detecting CXX compile features - done
 7-- Performing Test CXX_COMPILER_WORKS
 8-- Performing Test CXX_COMPILER_WORKS - Failed
 9CMake Error at cmake/module/EnableLanguage.cmake:42 (message):
10  The CXX compiler is not able to compile a simple test program.
11
12  Check that the "APPEND_*FLAGS" variables are set correctly.
13
14
15
16Call Stack (most recent call first):
17  CMakeLists.txt:71 (bitcoincore_enable_language)
18
19
20-- Configuring incomplete, errors occurred!
21hebasto@TS-P340:~/dev/bitcoin$ cmake -B build -DAPPEND_CXXFLAGS="-ftrivial-auto-var-init=zero"
22-- Performing Test CXX_COMPILER_WORKS
23-- Performing Test CXX_COMPILER_WORKS - Success
24...

hebasto added the label Build system on Apr 28, 2025

DrahtBot commented at 4:35 pm on April 28, 2025: contributor

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

Code Coverage & Benchmarks

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

Reviews

See the guideline for information on the review process.

Type	Reviewers
Stale ACK	janb84, BrandonOdiwuor

If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#34580 (build: Add a compiler minimum version check by polespinasa)
#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.

hebasto marked this as a draft on Apr 28, 2025

hebasto force-pushed on Apr 28, 2025

hebasto marked this as ready for review on Apr 28, 2025

hebasto force-pushed on Apr 28, 2025

janb84 commented at 9:16 am on April 29, 2025: contributor

ACK eb2a943

PR fixes #32323 (reproduced on main, checked it was solved by this PR) ✅
Code review looks good to me. Adds a new macro with additional checks and some optimisations.✅ (There is one reference to enable_languages() in secp256k1 but that is separate and not relevant to this PR )

Main:

Configure with faulty flag: cmake -B build -DAPPEND_CXXFLAGS="-ftrivial-auto-var-init"

expected config BREAK

Configure with correct flag: cmake -B build -DAPPEND_CXXFLAGS="-ftrivial-auto-var-init=zero" not expected: STILL BREAKS

This PR:

Configure with faulty flag cmake -B build -DAPPEND_CXXFLAGS="-ftrivial-auto-var-init" expected BREAK

Configure with correct flag cmake -B build -DAPPEND_CXXFLAGS="-ftrivial-auto-var-init=zero" config WORKS

DrahtBot added the label CI failed on Jul 30, 2025

DrahtBot removed the label CI failed on Jul 30, 2025

DrahtBot added the label Needs rebase on Aug 6, 2025

BrandonOdiwuor commented at 10:43 am on August 21, 2025: contributor

ACK eb2a9435044ac91442fafc606c5af2f473bff3c5

Confirmed that the new bitcoincore_enable_language(...) macro properly validates user-defined APPEND_*FLAGS early via check_source_compiles(...), fixing #32323 by catching bad flags during enable_language(…), and removing the need a clean build directory.

(system: macOS 15.6)

(branch: master)

(commit: eb2a9435044ac91442fafc606c5af2f473bff3c5)

hebasto marked this as a draft on Oct 6, 2025

fanquake commented at 11:43 am on February 13, 2026: member

@hebasto was this drafted for any particular reason?

hebasto force-pushed on Feb 13, 2026

hebasto marked this as ready for review on Feb 13, 2026

hebasto commented at 12:12 pm on February 13, 2026: member

@hebasto was this drafted for any particular reason?

Rebased and undrafted.

DrahtBot removed the label Needs rebase on Feb 13, 2026

DrahtBot added the label Needs rebase on Mar 5, 2026

cmake: Wrap `enable_language()` command in macro

This change introduces the `bitcoincore_enable_language()` macro to wrap
CMake’s `enable_language()` command, applying Bitcoin Core-specific
settings and checks.

9ef9b9d999

cmake: Move `APPEND_*` variables logic to `bitcoincore_enable_language`

This change is required for the following commit.

e83fb84b15

cmake: Check user-defined `APPEND_*` variables early

This change improves usability in cases where the user provides
`APPEND_*` variables that are incompatible with the compiler for some
reason.

cd9367c872

hebasto force-pushed on Mar 5, 2026

hebasto commented at 1:50 pm on March 5, 2026: member

Rebased to resolve conflicts.

DrahtBot removed the label Needs rebase on Mar 5, 2026

sedited requested review from purpleKarrot on Mar 11, 2026

purpleKarrot commented at 4:43 pm on March 11, 2026: contributor

What you are observing here is the so-called intervention spiral. You want to improve one aspect of cmake’s builtin behavior, there are unintended side effects, you add a workaround, which have side effects of their own and you need to add more workarounds until the whole system is complex beyond recognition.

The simple approach would be to respect user provided compile flags. Period.

A project that does not modify user provided compile flags does not need any additional mechanism to let the user “append” flags and it also does not need a custom way to enable languages. We should go back to the scratch board and discuss what that original intervention was that pulled in all those other workarounds.

fanquake commented at 4:55 pm on March 11, 2026: member

A project that does not modify user provided compile flags does not need any additional mechanism to let the user “append” flags

What about something like #31843 (https://gitlab.kitware.com/cmake/cmake/-/issues/26757), where the mechanism for the user to pass the flags they want (CMAKE_EXE_LINKER_FLAGS) doesn’t work?

purpleKarrot commented at 8:52 pm on March 11, 2026: contributor

@fanquake, is #31843 the reason why APPEND_*FLAGS were introduced? Is CMAKE_EXE_LINKER_FLAGS ignored?

purpleKarrot commented at 9:08 pm on March 11, 2026: contributor

The release notes for 29.0 contain:

If any of the CPPFLAGS, CFLAGS, CXXFLAGS or LDFLAGS environment variables were used in your Autotools-based build process, you should instead use the corresponding CMake variables (APPEND_CPPFLAGS, APPEND_CFLAGS, APPEND_CXXFLAGS and APPEND_LDFLAGS).

CMake does not use the APPEND_*FLAGS by default, but it actually does use the mentioned environment variables. But why is it mentioned that they should not be used?

sedited commented at 8:06 am on March 12, 2026: contributor

CMake does not use the APPEND_*FLAGS by default, but it actually does use the mentioned environment variables. But why is it mentioned that they should not be used?

We extensively debated the introduction during the migration. The APPEND_ flags were introduced to always have the last say, over build type, or any other cmake configuration. For more context, it was introduced here https://github.com/hebasto/bitcoin/pull/184 and superseded https://github.com/hebasto/bitcoin/pull/157 after a discussion here https://github.com/hebasto/bitcoin/pull/157#issuecomment-2090205960 .

fanquake commented at 8:21 am on March 12, 2026: member

Is CMAKE_EXE_LINKER_FLAGS ignored?

CMake doesn’t put the user supplied flags, last on the link line, meaning they are overriden by CMakes own PIC/PIE flags. So in this case, the user flags are effectively ignored by CMake.

hebasto commented at 9:30 am on March 12, 2026: member

The release notes for 29.0 contain:

If any of the CPPFLAGS, CFLAGS, CXXFLAGS or LDFLAGS environment variables were used in your Autotools-based build process, you should instead use the corresponding CMake variables (APPEND_CPPFLAGS, APPEND_CFLAGS, APPEND_CXXFLAGS and APPEND_LDFLAGS).

CMake does not use the APPEND_*FLAGS by default, but it actually does use the mentioned environment variables. But why is it mentioned that they should not be used?

Migrating from Autotools to CMake presented several challenges. Perhaps the most significant was that, over the years, users relied on the fact that any user-provided flags override whatever is set by the build system. This is generally not the case with CMake. Another minor issue is that CMake does not support CPPFLAGS.

cmake: Check user-defined APPEND_*FLAGS variables early #32367

Code Coverage & Benchmarks

Reviews

Conflicts

Main:

This PR:

cmake: Check user-defined `APPEND_*FLAGS` variables early #32367