Embed compiler flags into binary and show them in the version output

[julianbrost]

I'd like to put the following idea up for discussion:

We already include some information about the build environment, including the compiler version, see the following excerpt from icinga2 --version:

Build information:
  Compiler: GNU 14.2.0
  Build host: buildkitsandbox
  OpenSSL version: OpenSSL 3.5.1 1 Jul 2025

This could be extended with values like the CXXFLAGS used for compiling the icinga2 binary or maybe also some CMake variables that could be relevant (what could be relevant is still to be decided).

Origin of the idea

I've had this idea following #10505 (comment), where a wrong value passed to CMAKE_BUILD_TYPE resulted in the wrong flags being used. While having the flags used show up --version wouldn't have helped noticing the problem, it would have made it nicer to verify the issue.

Related work

We wouldn't be the first software project doing this: PostgreSQL already does this for example. There the compile flags can be shown with pg_config:

$ pg_config
BINDIR = /usr/bin
DOCDIR = /usr/share/doc/postgresql
HTMLDIR = /usr/share/doc/postgresql
INCLUDEDIR = /usr/include
PKGINCLUDEDIR = /usr/include/postgresql
INCLUDEDIR-SERVER = /usr/include/postgresql/server
LIBDIR = /usr/lib
PKGLIBDIR = /usr/lib/postgresql
LOCALEDIR = /usr/share/locale
MANDIR = /usr/share/man
SHAREDIR = /usr/share/postgresql
SYSCONFDIR = /etc/postgresql
PGXS = /usr/lib/postgresql/pgxs/src/makefiles/pgxs.mk
CONFIGURE =  '--prefix=/usr' '--sysconfdir=/etc' '--mandir=/usr/share/man' '--datadir=/usr/share/postgresql' '--disable-rpath' '--enable-nls' '--enable-tap-tests' '--with-gssapi' '--with-icu' '--with-ldap' '--with-libxml' '--with-libxslt' '--with-llvm' '--with-lz4' '--with-openssl' '--with-pam' '--with-perl' '--with-python' '--with-readline' '--with-system-tzdata=/usr/share/zoneinfo' '--with-systemd' '--with-tcl' '--with-uuid=e2fs' '--with-zstd' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection         -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/build/postgresql/src=/usr/src/debug/postgresql -flto=auto -ffat-lto-objects' 'LDFLAGS=-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now          -Wl,-z,pack-relative-relocs -flto=auto' 'CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection         -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wp,-D_GLIBCXX_ASSERTIONS -g -ffile-prefix-map=/build/postgresql/src=/usr/src/debug/postgresql -flto=auto'
CC = gcc
CPPFLAGS = -D_GNU_SOURCE -I/usr/include/libxml2
CFLAGS = -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection         -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/build/postgresql/src=/usr/src/debug/postgresql -flto=auto -ffat-lto-objects
CFLAGS_SL = -fPIC
LDFLAGS = -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-z,pack-relative-relocs -flto=auto -L/usr/lib -Wl,--as-needed
LDFLAGS_EX = 
LDFLAGS_SL = 
LIBS = -lpgcommon -lpgport -lzstd -llz4 -lxslt -lxml2 -lpam -lssl -lcrypto -lgssapi_krb5 -lz -lreadline -lm 
VERSION = PostgreSQL 17.5

[jschmidt-icinga]

The only way I know to reliably get the full list of compile commands from CMake is the CMAKE_EXPORT_COMPILE_COMMANDS=ON setting generating a compile_commands.json file in the build directory, which LSP servers and thus IDEs use. But the format of that file is well defined and could be parsed (using CMake's (version >=3.19) built-in JSON support) and transformed into a generated .cpp file before building the main target.

[jschmidt-icinga]

I've looked a bit more into this yesterday and CMAKE_EXPORT_COMPILE_COMMANDS=ON doesn't work with VS builds and doesn't work properly with CMakes own unity builds, which we might eventually switch to (#10404).

So instead the best bet is probably to apply a wrapper script to the CXX_COMPILER_LAUNCHER target property of a new dummy target that compiles a dummy cpp file (doesn't even have to be a real file). The wrapper dumps the compiler flags into a header file we can include. The question is how to do that in a platform-independent way.

[julianbrost]

Hold on a second, IMHO this would be more of a nice to have feature. If CMake makes it hard to do this, I doubt it's worth the complexity.