I often compile old versions of MySQL, MariaDB, Postgres and RocksDB in my search for performance regressions. Compiling is easy with Postgres as they do a great job at avoiding compilation warnings and I never encounter broken builds. Certainly the community gets the credit for this, but I suspect their task is easier because they use C. This started as a LinkedIn post.
I expect people to disagree, and I am far from a C++ expert, but here goes ...
tl;dr - if you maintain widely used header files (widely used by C++ projects) consider not removing that include that you don't really need (like <cstdint>) because such removal is likely to break builds for older releases of projects that use your include.
I have more trouble compiling older releases of C++ projects. For MySQL I have a directory in github that includes patches that must be applied. And for MySQL I have to patch all 5.6 versions, 5.7 versions up to 5.7.33 and 8.0 versions up to 8.0.23. The most common reason for the patch is missing C++ includes (like <cstdint>).
For RocksDB with gcc I don't have to patch files but I need to use gcc-11 for RocksDB 6.x and gcc-12 for RocksDB 7.x.
For RocksDB with clang I don't have to patch files for RocksDB 8.x, 9.x and 10.x while I do have to patch 6.x and 7.x. For RocksDB 7.10 I need to edit two files to add <cstdint>. The files are:
- table/block_based/data_block_hash_index.h
- util/string_util.h
- Rather than remember which of V= and VERBOSE= that I need, I just use both
- I get errors if I don't define AR and RANLIB when using clang
- While clang-18 installs clang and clang++ binaries, to get the llvm variants of ar and ranlib I need to use llvm-ar-18 and llvm-ranlib-18 rather than llvm-ar and llvm-ranlib
AR=llvm-ar-18 RANLIB=llvm-ranlib-18 \
CC=clang CXX=clang++ \
make \
DISABLE_WARNING_AS_ERROR=1 DEBUG_LEVEL=0 V=1 VERBOSE=1 -j... \
CC=clang CXX=clang++ \
make USE_LTO=1 \
DISABLE_WARNING_AS_ERROR=1 DEBUG_LEVEL=0 V=1 VERBOSE=1 -j... \
static_lib db_bench
