cmake build summary could be clearer

[real-or-random]

Note: This also affects libsecp256k1, where I noticed it. The summary is similar there, which is a good thing. Reporting here to get more feedback.

Here's a snippet of a build summary from libsecp256k1 (from bitcoin-core/secp256k1#1532 / f55703ba49454fc46226f4846fe292d4a3dfa3ef):

Preprocessor defined macros ........... ENABLE_MODULE_ELLSWIFT=1 ENABLE_MODULE_SCHNORRSIG=1 ENABLE_MODULE_EXTRAKEYS=1 ENABLE_MODULE_RECOVERY=1 ENABLE_MODULE_ECDH=1 ECMULT_WINDOW_SIZE=15 COMB_BLOCKS=11 COMB_TEETH=6 USE_ASM_X86_64=1 VALGRIND
C compiler ............................ Clang 17.0.6, /usr/lib/ccache/bin/clang
CFLAGS ................................ -fsanitize=memory -O2
Compile options ....................... -pedantic -Wall -Wcast-align -Wconditional-uninitialized -Wextra -Wnested-externs -Wno-long-long -Wno-overlength-strings -Wno-unused-function -Wreserved-identifier -Wshadow -Wstrict-prototypes -Wundef -fno-sanitize-memory-param-retval
Build type:
 - CMAKE_BUILD_TYPE ................... RelWithDebInfo
 - CFLAGS ............................. -O2 -g 
 - LDFLAGS for executables ............ 
 - LDFLAGS for shared libraries ....... 

I think, the entries are a bit confusing, both for people unfamiliar with CMake, but also even for people who know about CMake's internals:

• There are two entries for "CFLAGS" plus "compile options", which has also some CFLAGS.
• There's just the term "Preprocessor defined macros", but no mention of CPPFLAGS.

I'm not sure what the best way is to resolve this, but I'm thinking something like this, i.e., have textual descriptions for the "normal" dev and perhaps also CMake's internal names for build system experts (not sure if that's too much):

CPPFLAGS for the main source directory (COMPILE_DEFINITIONS) .....
CFLAGS applied globally (CMAKE_C_FLAGS) .....
CFLAGS for the main source directory (COMPILE_OPTIONS) .....
CFLAGS implied by the build type .....

This is just a sketch, it can certainly be improved a lot, and some bike-shedding will be necessary. And note that I know a bit about CMake, but I'm certainly not an expert, so I'm not exactly sure if my interpretation is even correct.

Ideally, the listing of flag variables would be in the same order as they'll appear on the final compiler command line. Not sure if this is even possible considering all special cases, etc, but it will be good as a rule of thumb.

[hebasto]

@real-or-random

There are two competing PRs that aim to improve the summary:

• [FIXUP] cmake: Rework compile/link flags summary #93
• [POC] cmake: Rework compile/link flags summary -- an alternative implemenation #218

Do they look like an improvement for you?