[RFC] cmake: Build option naming

[hebasto]

All build options effectively are cache variables, whose values persist across multiple runs within a project build tree.

From the Professional CMake: A Practical Guide 18th Edition:

Cache variables are primarily intended as a customization point for developers.

The current (@ 9857482) build option set being presented in the CMake GUI tool looks as follows:

Please note that selecting the "Grouped" checkbox groups variables together based on the start of the variable name up to the first underscore. CMake reserves names that begin with CMAKE_.

1. The group of BUILD_* options is presented in the "Executables" and "Tests" sections of the "Configure summary".

Please note, that CMake's CTest module:

automatically creates a BUILD_TESTING option...

2. The group of WITH_* options is presented in the "Wallet support" and "Optional packages features" section of the "Configure summary".

However, the MULTIPROCESS option has no WITH_ prefix.

3. Switching to upstream CMake-based build systems for subtrees (see cmake: Switch to libsecp256k1 upstream build system #192) will expose their own options. Thus, libsecp256k1 introduces SECP256K1_* names.

---

This issue aims to gather suggestions and opinions regarding better naming. Please vote for each suggestion using 👍 for approval and 👎 for disapproval.

[hebasto]

ENABLE_WALLET --> WALLET

[hebasto]

cc @ryanofsky @achow101 @maflcko

[theuni]

I like the BUILD_/WITH_/ENABLE_ groups personally. I think that's a nice split.
BUILD_: add a binary/library
WITH_: allow a dependency
ENABLE_: turn on a feature

[ryanofsky]

I haven't looked into this, and I might have an uninformed or minority opinion, but having WITH_ and ENABLE_ prefixes in most cases does make sense to me.

I think WITH_ options should control what dependencies are turned on. ENABLE_ options should control what features are turned on. BUILD_ options should control what binaries and libraries are built by default (when you run make).

For example, for multiprocess, there could be WITH_CAPNP to control whether the find_package(CapnProto) is called and that protocol is available, WITH_GRPC to control whether find_package(gRPC) is called and that protocol is available, and ENABLE_MULTIPROCESS to control whether multiprocess features will be enabled using the previous packages.

For the wallet, there could be WITH_SQLITE and WITH_LMDB options to enable those packages and ENABLE_WALLET to enable wallet features.

For the gui, there could be WITH_QT5, WITH_QT6, and ENABLE_GUI.

(I know we don't like having dependencies, so these examples are theoretical, but I think we should still choose a naming convention that can accommodate having dependencies cleanly.)

In some of these examples, the features controlled by ENABLE_ flags are built as standalone binaries, so having the ENABLE_ option is redundant, and a BUILD_ flag is sufficient. For example, the GUI lives in a separate bitcoin-qt binary from bitcoind so having ENABLE_GUI would be redundant and BUILD_GUI would be sufficient. The multiprocess binary bitcoin-node is also currently separate from bitcoind so having ENABLE_MULTIPROCESS would be redundant and having just BUILD_MULTIPROCESS would be sufficient for now. But wallet features are currently built into bitcoind so there should be an ENABLE_WALLET option to allow building with or without those features, and a separate WITH_SQLITE option to control whether the sqlite database library is used. (Assuming we drop bdb support, building with WITH_SQLITE=OFF and ENABLE_WALLET=ON would fail, but that seems fine. Not every combination of build flags that could work theoretically needs to be supported in practice.)

I also don't like the the convention of having options like MULTIPROCESS or WALLET without any prefixes at all. CMake builds can have dozens of options, or more, so I think ENABLE_ WITH_ and BUILD_ prefixes provide useful groupings and an indication of what the types of options are and what they do.

Looking at the screenshot in #194 (comment), I think in practice this just means that more variables would get prefixes. CCACHE > WITH_CCACHE, FUZZ > ENABLE_FUZZ, HARDENING > ENABLE_HARDENING, MULTIPROCESS > BUILD_MULTIPROCESS WITH_LIBMULTIPROCESS, THREADLOCAL > ENABLE_THREADLOCAL. And some names might change: WITH_EXTERNAL_SIGNER > ENABLE_EXTERNAL_SIGNER.

This is just my (not completely informed) preference though. There could be things I'm overlooking, and I wouldn't have a problem with a different approach.

(EDIT: Changed BUILD_MULTIPROCESS to WITH_LIBMULTIPROCESS as explained #198 (comment))

[hebasto]

Closing as resolved by #198.