Cmake with or without ninja or a more consistent usage in the wiki

[userdocs]

I have been looking at using cmake with my script and whilst i have an ok understanding of the process and can build with consistent outcomes but I have one particular question regarding an inconsistent usage of cmake ninja build in the wiki.

What is the verdict on whether ninja should be installed and used by default or explained as an optional step in all cmake related build guides?

The reasoning behind this question is as follows.

When I looked across the available guides ( to be clear this is not a complaint about the guides they were very helpful ) i found this inconsistent usage:

Common Info - It's optional and recommend here

Debian and Ubuntu - It's used and assumed default with no context here

OSX - It's not used at all here and the build process is different for it

I found the OSX build process more helpful to understand as it was just using cmake directly and it was easier to troubleshoot as the ninja build method is very quiet by default. Adding this make it more verbose if needed and works for with or without ninja.

-D CMAKE_VERBOSE_MAKEFILE=ON

It's not a big deal but I think I would have found it easier if there was a more consistent build method across platforms as well as perhaps ninja being a recommended once you have a working , verbose cmake build process. I think this would make it easier for a cmake novice to get up and running and troubleshoot problems easier.

Then apply ninja build to get the faster build.

So working on Alpine using cross building I am doing something this.

cmake -G "Ninja" -B build \
    -D CMAKE_VERBOSE_MAKEFILE=ON \ # optional
    -D CMAKE_CXX_COMPILER=aarch64-linux-musl-g++ \ # optional
    -D CMAKE_BUILD_TYPE="Release" \ # The build type (no debug?)
    -D CMAKE_CXX_STANDARD="17" \ # The CXX standard
    -D CMAKE_CXX_FLAGS="-static -Wno-deprecated-declarations" \  # optional static linking and no deprecated warnings
    -D CMAKE_PREFIX_PATH="${qb_install_dir};${qb_install_dir}/boost" \ # optional semi colon separated list of paths
    -D CMAKE_CXX_STANDARD_LIBRARIES="${lib_dir}/libssl.a ${lib_dir}/libcrypto.a" \ # optional link evasive libs
    -D STACKTRACE=OFF -DGUI=OFF -DCMAKE_INSTALL_PREFIX="${qb_install_dir}" # customised prefix
cmake --build build --parallel "$(nproc)"

[FranciscoPombal]

@userdocs

as it was just using cmake directly

There is no such thing as "using CMake directly", as opposed to "not using it directly". The CMake build has basically 3 stages:

1. Configuration: where CMake builds an internal representation of the build
2. Generation: where CMake turns the internal representation of the build generated in 1. and generates a script for consumption by a "generator" (ninja, make, XCode, etc), that will actually execute the build.
3. The build itself. You can use the "generator" directly, or use CMake to drive any generator with cmake --build <build_folder> <options>

Steps 1 and 2 are typically though of as a single step, especially because CMake does both sequentially when the user is "configuring". That's why at the end of a CMake "configuration" you see "Configuring done. Generating done".

CMake itself never actually "builds" (in the sense of generating object files from source code) your project.

Ninja just happens to be the better option to choose as a generator the vast majority of the time. You can certainly control the verbosity of the generated ninja build file, and one thing that's also exceptionally useful is to use -DCMAKE_EXPORT_COMPILE_COMMANDS=ONin the configure command line, for troubleshooting and other purposes (such as feedingclangd`).

---

That being said, I agree that the advice should be consistent. We should always recommend and assume Ninja by default, but also mention that anyone can choose a different generator, if they need to. Apple may still be an exception to this rule, since their closed-down

So working on Alpine using cross building I am doing something this.

For cross-compiling, you probably want to look into CMake toolchain files (e.g. -DCMAKE_TOOLCHAIN_FILE= ... ).
The best resource for learning CMake is Craig Scott's book, Professional CMake. It's $30, but well worth it.

[userdocs]

Since qbittorrent is difficult to build in the best of circumstances I think a verbose and easy to debug method should be first with the fine tuning applied after.

If I use cmake without ninja the output I generally a bit more verbose and more helpful. That is what I noticed.

Once I have it working it's ok to apply ninja, even though I need to build it on alpine since there is no release past version 3.11 for some reason.

I was considering if I needed to make a toolchain file but right now I don't need it. The alpine toolchain works as long as I use -D CMAKE_CXX_COMPILER=aarch64-linux-musl-g++" it works fine so i guess i can skip that for now.

Also, I found out that when making a release the bin are not stripped. I need to do this to have my binaries stripped and be comparable to the qmake builds in size. I think the strip options should be in the docs.

-D CMAKE_CXX_FLAGS="-s" \

[userdocs]

Also, this is a problem. I must create this path as root.

mkdir -p /usr/sfw/include

It's related to this line specifically PkgConfig::LIBTORRENT_RASTERBAR

https://github.com/qbittorrent/qBittorrent/blob/master/src/CMakeLists.txt#L17

If this directory does not exist, cmake bugs out.

[userdocs]

Ok, so i better understand that issue. This line https://github.com/qbittorrent/qBittorrent/blob/master/src/CMakeLists.txt#L3 is returning NOT found an i'm moving to the if section.

I can resolve this by creating my pkg config but really it's odd that it's not finding the lib

[FranciscoPombal]

@userdocs

Since qbittorrent is difficult to build in the best of circumstances I think a verbose and easy to debug method should be first with the fine tuning applied after.

I'm happy to help improve qBittorrent's CMake build system for your use case, just post your list of grievances. It's likely that some things may not be as optimized as they could, since I almost never build qBittorrent the way you do (fully static, etc). For me, simply executing the following "just works":

cmake -G Ninja -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build

I aim to make the experience as easy as this for as many use cases as possible.

---

If I use cmake without ninja the output I generally a bit more verbose and more helpful. That is what I noticed.

Ninja can output all build command lines in any of 3 ways (I checked and they all worked for me, i'm using 3.20.2 but I remember this all working as far back as 3.16.x):

• By passing -DCMAKE_VERBOSE_MAKEFILE=ON at configure-time.
• By passing --verbose at build-time (example: cmake --build build --verbose)
• By passing the -v flag directly to Ninja at build-time (example: cmake --build build -- -v - with CMake's build signature invocation, all flags specified after the -- are passed to the underlying build tool, which in this case is Ninja of course).

Also, this may also be of use to you, for interoperability with tools such as clangd: https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html

Once I have it working it's ok to apply ninja, even though I need to build it on alpine since there is no release past version 3.11 for some reason.

If you need a more recent version of CMake, compiling it from source is pretty easy.

I was considering if I needed to make a toolchain file but right now I don't need it. The alpine toolchain works as long as I use -D CMAKE_CXX_COMPILER=aarch64-linux-musl-g++" it works fine so i guess i can skip that for now.

Also, I found out that when making a release the bin are not stripped. I need to do this to have my binaries stripped and be comparable to the qmake builds in size. I think the strip options should be in the docs.

-D CMAKE_CXX_FLAGS="-s" \

This is exactly the problem that toolchain files solve. Instead of passing a bunch of flags that really just describe the basics of the toolchain you are using among all the other flags, you define them in a a toolchain file. Also, it is actually more appropriate to use the *_FLAGS_INIT variables in this case (example: https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_FLAGS_INIT.html). Plus, toolchain files do a bunch of little things under the hood, which are otherwise not done, which could be causing some of your problems.

For instance, here is what a toolchain file for alpine might look like (named AlpineAarch64Musl.cmake, for instance):

set(CMAKE_SYSTEM_NAME "Linux")
set(CMAKE_SYSTEM_PROCESSOR "aarch64")

set(CMAKE_C_COMPILER "aarch64-linux-musl-gcc")
set(CMAKE_CXX_COMPILER "aarch64-linux-musl-g++")
set(CMAKE_C_FLAGS_INIT "-s")
set(CMAKE_CXX_FLAGS_INIT "-s") 
# uncomment if you need to customize
#set(CMAKE_EXE_LINKER_FLAGS_INIT "-foo")
#set(CMAKE_SHARED_LINKER_FLAGS_INIT "-bar")
#set(CMAKE_MODULE_LINKER_FLAGS_INIT "-baz")
#set(CMAKE_STATIC_LINKER_FLAGS_INIT "-qux")
# other potentially interesting customization points when cross-compiling:
#set(CMAKE_STAGING_PREFIX "something...")
#set(CMAKE_SYSROOT "something...")

Then you just need to to pass -DCMAKE_TOOLCHAIN_FILE=AlpineAarch64Musl.cmake at configure-time. It is unlikely that you need anything more than this.

---

If this directory does not exist, cmake bugs out.

Please post the logs/errors when documenting such cases, otherwise I can't see what exactly is going on.

Ok, so i better understand that issue. This line https://github.com/qbittorrent/qBittorrent/blob/master/src/CMakeLists.txt#L3 is returning NOT found an i'm moving to the if section.

I can resolve this by creating my pkg config but really it's odd that it's not finding the lib

You are misunderstanding the problem. It's find_package(LibtorrentRasterbar QUIET ${minLibtorrentVersion} COMPONENTS torrent-rasterbar) that is returning NOT FOUND. This means that CMake found no CMake config module for the library. In the case of libtorrent, such config module is only installed if you build it with CMake as well. Otherwise, only the pkgconfig is installed, which is what CMake uses. As to why it bugs out in

qBittorrent/src/CMakeLists.txt

Line 17 in 365b1c6

add_library(LibtorrentRasterbar::torrent-rasterbar ALIAS PkgConfig::LIBTORRENT_RASTERBAR)

under the conditions you describe, I have no idea. Maybe due to some Alpine quirk? I cannot reproduce the issue on my systems (none of them Alpine).

[userdocs]

1: It would make sense to factor those options into the build doc so users unfamiliar with using cmake or building in general are using verbose and helpful options by default.

2: The stripping should be included by default other simply doing cmake/cmake build/cmake install is not equivalent to the qmake method unless extra flags are passed. I don't see why this should be passed on to the end user to solve. A release build should create an equivalent outcome to qmake's release build. The cross building part is unrelated to this and it's not necessary to do anyway.

3: The problem (debian based or alpine btw) is that when you use libtorrent's recommended and documented build system b2 you do not get a package config file generated. So at this step when it looks for the package config file it does not find it and seems to fall back to defaults instead. I an unsure is happening exactly in the absence of the file i am guessing it is pkgconfig though. Currently this has left me is a odd situation with cmake as either

• create the directory /usr/sfw/include as root (problematic) and bypass the bug which is causeing cmake to fail at the absence of this directory. The you need to appreciate that we are loading and linking these libs without pkg-config. Libtorrent is still found and loaded. Through passing the libs like I do with openssl and they being detected that way.
• generate my own --prefix/lib/pkgconfig file for libtorrent to not trigger the bug. This what I have decided to do using strings

libtorrent_strings_version="$(strings -d "${lib_dir}/libtorrent-rasterbar.a" | grep -Eo "^libtorrent/[0-9]\.(.*)")" # ${libtorrent_strings_version#*/}

And I create it like this

prefix=${qb_install_dir}
exec_prefix=\${prefix}
libdir=\${exec_prefix}/lib
includedir=\${prefix}/include

Name: libtorrent-rasterbar
Description: The libtorrent-rasterbar libraries
Version: ${libtorrent_strings_version#*/}

Requires:
Libs: -L\${libdir} ${libtorrent_libs}
Cflags: -I\${includedir} -I${BOOST_ROOT}

I have asked about it here arvidn/libtorrent#6211

But either way you need to appreciate that using the b2 method, which is the main method for that project, does not create a pkg file so the build process would need to accommodate for that.

4: Really the main oddness with building fully static and not relying on package config file is you need to pass the libs to the linked manually. The creates situations with the built in checks/config doing one thing and the build does another. To be honest it really makes things odd as you can have failures to config with successful builds and vice versa.

[FranciscoPombal]

@userdocs

1: It would make sense to factor those options into the build doc so users unfamiliar with using cmake or building in general are using verbose and helpful options by default.

Me and others would strongly disagree with enabling verbose options by default, but I do agree that there is no harm in documenting the options for increasing verbosity on the wiki.
However, keep in mind that though it is always nice to brush over the basics in our own documentation, ultimately it is not our responsibility to teach the user how to use CMake in general.

2: The stripping should be included by default other simply doing cmake/cmake build/cmake install is not equivalent to the qmake method unless extra flags are passed. I don't see why this should be passed on to the end user to solve. A release build should create an equivalent outcome to qmake's release build. The cross building part is unrelated to this and it's not necessary to do anyway.

CMake provides a native target for this purpose. It's called install/strip (at least when using Ninja, but i believe the name is the same regardless of the generator used). You can use it like so: cmake --build build --target install/strip. This will install to the default install prefix, which you can of course override at configure-time with -DCMAKE_INSTALL_PREFIX=/some/path.

To list all the available targets, use cmake --build build --target help.

Of course, only the installed executable will be stripped, not the one in the build dir. If stripping unconditionally for both the build dir and install dir when compiling in Release mode is what you want, that is an easy fix as well. I can submit a draft PR for that and see if others are also on board with it.

3: The problem (debian based or alpine btw) is that when you use libtorrent's recommended and documented build system b2 you do not get a package config file generated. So at this step when it looks for the package config file it does not find it and seems to fall back to defaults instead. I an unsure is happening exactly in the absence of the file i am guessing it is pkgconfig though. Currently this has left me is a odd situation with cmake as either

I believe even with b2 a pkgconfig file should have been generated. Also, the implication that it is not recommended to build libtorrent with CMake or that it is not documented is false. It is mentioned in the official docs (they even mention usage of vcpkg, which of course uses CMake). It is what I have always used, it is what is used in our CI. IMO it is simply better because it generates CMake config files that other projects that use CMake (such as qBittorrent) can consume. These files contain all the necessary information about build and usage requirements of libtorrent, and ensure everything is propagated properly. I believe libtorrent's CMake also generates an reasonable pkg-config file that can be used by projects which do not use CMake.

If the way you're building libtorrent does not generate the necessary files containing information necessary for other projects to properly consume libtorrent as a dependency, that's either a problem with the way you're building it or with its b2 build system.

But either way you need to appreciate that using the b2 method, which is the main method for that project, does not create a pkg file so the build process would need to accommodate for that.

No. Sorry, but as I said above this is not the responsibility of a downstream project.

4: Really the main oddness with building fully static and not relying on package config file is you need to pass the libs to the linked manually. The creates situations with the built in checks/config doing one thing and the build does another. To be honest it really makes things odd as you can have failures to config with successful builds and vice versa.

At least with CMake, building fully static should not be a problem in principle, as long as everything is being done properly. It can perfectly keep track of everything, we just have to squash whatever bugs there are, if any.

[userdocs]

1: i'll come back to this later but I think it's good to have it in the docs. The minute you step outside of the OS default apps, like QT, things get complicated and the more informative the build process is the better. What I am doing Is not standard but realistically we have a project that relies on 3 major dependencies across two/three build systems and as soon and you want an updated version, you step into what i'm doing.

2: The point is if I am using qmake and I change to cmake I would expect an equivalent outcome. What we appear to have is an undocumented change to the build process that left me wondering what I was doing wrong to be getting much larger binaries. So I think this comes does to either document the change in approach or maintain the build style from qmake to > cmake. I feel it release should be stripped by default. If everyone else disagreed then document the change and reason.

3: This b2 package config thing might be having more of an effect than I realised and it seems to have solved many other linking issues. I am doing more testing

I have not built libtorrent with cmake to seem if it give the same outcome. i'll do that as well.

[FranciscoPombal]

@userdocs

1. Yes, we agree it should at least be documented.

2. Yes, I agree. In fact, it also seems better to me to strip by default on Release builds. Here is a PR implementing that change, plus fixing a bug I found in the meantime: CMake: Fix compiler ID checks #14995.

3. Yes. pkgconfig files, CMake config files, etc all contain important information about build and usage requirements (defines, includes, compile/link options... and their transitivity, or not) that dependees need to know about in order to link against the dependency successfully. Except for very trivial cases, linking against a library is not simply a matter of listing the .so or .a files in the linker command-line.

I have not built libtorrent with cmake to seem if it give the same outcome. i'll do that as well.

I recommend building libtorrent with CMake. Here is a configure command-line you can use: cmake -B cmake-build-dir -G "Ninja" -DCMAKE_BUILD_TYPE=Release -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -Dbuild_examples=ON -Dbuild_tools=ON -Ddeprecated-functions=OFF -Ddeveloper-options=ON. For your use-case, you also probably need -DBUILD_SHARED_LIBS=OFF and -Dstatic_runtime=ON. Then just build with cmake --build cmake-build-dir as usual, and install it (by default to the /usr/local prefix) with sudo cmake --install cmake-build-dir.

What I am doing Is not standard but realistically we have a project that relies on 3 major dependencies across two/three build systems

All the more reason to try to use only one build system as much as possible. For better or worse, CMake has more or less achieved critical mass in the C++ world. If you stick with it and actually know how to use it, things are usually simpler.

• Qt has now officially transitioned to CMake, but even Qt5 provided excellent support for building against it with CMake (it provided proper CMake config files).
• Similarly, modern Boost versions have 1st class CMake support, even though Boost itself is not built with CMake.
• OpenSSL doesn't have good integrations with CMake, but it is supported via the officially bundled FindOpenSSL module. Same with zlib. The CMake devs maintain these modules upstream due to the ubiquity of these dependencies.
• libtorrent also has great CMake support. It is not quite up to par with b2 feature-wise, but you would only notice this if you were developing libtorrent itself. All the important features for consumers of the library are there already, and have been for a long time.
• Even if a project only offers a pkgconfig, CMake has an officially bundled module to deal with that. The information that a pkgconfig file can provide to dependees is often not as expressive as a native CMake config file, but it is often good enough.
• Finally, if you really wanted to use something that doesn't provide 1st-party CMake config files or pkgconfigs and for which the CMake distribution does not bundle an official find module, you can always write it yourself. Or, if you're lazy (smart?), you use vcpkg to install that dependency, if possible, because vcpkg ports are guaranteed to install usable usage/build requirements files that other CMake-based projects can consume.

Good luck with your testing!

[userdocs]

For the doc i think this info will be very handy https://cliutils.gitlab.io/modern-cmake/chapters/features/debug.html specifically these kind of commands. These help me understand the iconv issue and where it was coming from.

This is particularly helpful, to get a specific search.

cmake --trace-expand -B build |& grep -C "iconv"

And this

cmake -S . -B build --trace-source=CMakeLists.txt

Realistically when we are talking about building qbittorrent this is what we are looking at and it is complicated.

Build systems links

Deps	Debian based	Alpine	make	cmake	b2	qmake
bison	✅	❌	✅	❌	❌	❌
gawk	✅	❌	✅	❌	❌	❌
glibc	✅	❌	✅	❌	❌	❌
zlib	✅	✅	✅	❌	❌	❌
iconv	✅	✅	✅	❌	❌	❌
icu	✅	✅	✅	❌	❌	❌
openssl	✅	✅	✅	❌	❌	❌
boost	✅	✅	✅	❌	✅	❌
libtorrent	✅	✅	✅	✅	✅	❌
qtbase	✅	✅	❌	❌	❌	✅
qtools	✅	✅	❌	❌	❌	✅
qbittorrent	✅	✅	❌	✅	❌	✅

Dependency relationships

links	zlib	openssl	iconv	icu	libtorrent	qtbase	qbittorrent
zlib	NA	✅	❌	❌	✅	✅	✅
openssl	✅	NA	❌	❌	✅	✅	✅
iconv	❌	❌	NA	❌	✅	✅	?
icu	❌	❌	❌	NA	?	✅	?
libtorrent	✅	✅	✅	?	NA	❌	✅
qtbase	✅	✅	✅	✅	❌	NA	✅
qbittorrent	✅	✅	?	?	✅	✅	NA

I have mostly resolved these issues for my build process now.

[FranciscoPombal]

@userdocs

How should this table be interpreted? It's a little bit confusing. But I assume you're tracking the different ways each dependency can be built on both Debian and Alpine, all the way down to the libc.

Again, if there is anything that can be done on our end to improve some deficiency of the CMake build, let me know.

[userdocs]

I thought the best way to answer that was a more complicated table! Being serious, I think I started to mix build systems links with dependency links so separated them out into two tables in my previous post.

This is what is being juggled if we are looking to build using dependencies not provided by the system packet manager.

The current version of my build script I will soon push after matrix testing can now handle most, if not all of these as I just added cmake to it for build libtorrent and qbittorrent.

Really i would like two things as outcomes from this.

1: a better relationship between libtorrent cmake process and qbittorrent.

2: some tweaks to the cmake wiki docs so that build process includes a few additional tips and steps.

[FranciscoPombal]

@userdocs

Can you elaborate on points 1 and 2 (no need to mention executable stripping which is ready being looked into in a PR)?

I would be especially interested in knowing what can be improved concerning qbittorrent and libtorrent's CMake.
As far as I know the most important cases are covered: qbittorrent uses find_package() to try to find CMake config files for libtorrent, and if that fails, it tries the pkgconfig.

[FranciscoPombal]

Also thanks for splitting the tables.

It occurs to me that the "dependency links" table would be better expressed as a dependency graph instead.

With CMake, you can pass --graphviz=dep_graph.dot at configure-time to generate a graphviz dot file, which you can then convert to an image with dot -Tpng -o dep_graph.png dep_graph.dot. This way, you can check the relationships between dependencies for CMake-based projects against what you expect/want them to be (including transitivity properties).

[userdocs]

1: is expanded as that for now I think attention should be turned here arvidn/libtorrent#6215 so that the pkgconfig files and or cmake files are generated in way that creates seamless build experience with qbittorrent. I think a lot of my linking issues arose from these files. and when I generated my own on lib/pkgconfig they were overridden. For example I have never seen this -lIconv::Iconv

2: With the docs, I think it is safe to say people are moving away from system deps to custom builds for qbit because it's moving faster than they do and right now they are a serious bottle neck. So it may call for separate guide that covers more options and provides verbose first, fine tune later approach to building as to make sure all the pieces are fitting together as wanted. Command like this were very helpful (credits to #cmake:matrix.org).

cmake --trace-expand -B build |& grep -C "iconv"

I'll try that image thing to see what i get. it sounds useful.

[userdocs]

[FranciscoPombal]

@userdocs

Looks about right.
If you want, you can compare these graphs to the ones produced by the CI builds, so that you can see how they stack up against the ones produced by dynamic builds.

The qBittorrent graph looks a bit messy due to all the Qt components, but that's fine. If you want to see what's going on more clearly, I think there are some options that you can pass to graphviz to make the graph generation more sparse.

Finally, in case you don't know, a little explanation on the meaning of the different line styles and the meaning of "public" vs "private" vs "interface" with regards to the dependency relationships in CMake:

• Dotted line A->B: B is a private dependency of A. This means A requires (components of) B for its own build, or, in other words, B is a build requirement of A. However, B is not a usage requirement of A, so it does not transitively propagate as a build requirement for a hypothetical target C that depends on A.

• Dashed line A->B: B is an interface dependency of A. This means A does not require B for its own build, or, in other words, B is not a build requirement of A. However, B is a usage requirement of A, so it transitively propagates as a build requirement for a hypothetical target C that depends on A.

• Solid line A->B: B is a public dependency of A. This means A requires (components of) B for its own build, or, in other words, B is a build requirement of A. Additionally, B is a usage requirement of A, so it transitively propagates as a build requirement for a hypothetical target C that depends on A. In CMake, "public" really means "interface+private".

[userdocs]

I could remove a few qt based libs by not using ICU but it's still a bit crazy.

First image was cmake + libtorrent 1.2.13 second is v2.0.3.0 and third is cmake + qbittorrent.

[FranciscoPombal]

@userdocs

/offtopic

First image was cmake + libtorrent 1.2.13 second is v2.0.3.0 and third is cmake + qbittorrent.

Interesting, looking closer at the libtorrent graphs, it looks like there could be a redundant public dependency between the torrent-rasterbar target and the OpenSSL::Crypto target in 1.2.13 (the extra solid arrow that is not there in the 2.0.3 graph).

[userdocs]

I stuck my graph in here instead as i could not get a similar output from graphiz https://www.yworks.com/yed-live/.

[FranciscoPombal]

Looks nice, but the legend looks wrong and it seems the arrow style of interface and private dependencies is the same, unfortunately.

[userdocs]

I'll try to work up some of the points raised and draft some wiki edits to see what you think towards making the cmake docs a bit better but it won't be super quick. I'll give it a try though.

[userdocs]

Anything here that might be useful? They have a variety of build advice.

https://weechat.org/files/doc/devel/weechat_user.en.html#compile_with_cmake

[FranciscoPombal]

@userdocs

Thanks, but I think we've already got similar stuff:

• Table with option descriptions: https://github.com/qbittorrent/qBittorrent/wiki/Compilation-with-CMake:-common-information
• Build/install commands: https://github.com/qbittorrent/qBittorrent/wiki/Compilation:-Debian,-Ubuntu,-and-derivatives (and ours is better because we use the generic cmake --build build for the build step as opposed to a specific invocation of a tool like make).
• cmake -LA (or -LAH), or ccmake/CMake GUI: It is assumed the user knows about this, since this is basic CMake usage... plus it is not very useful since it shows every cache variable, including stuff that you would not want to change manually yourself. qBittorrent only has a handful of configurable options that are easy to keep track of.
• Building and running with ASAN or other sanitizers: not implemented yet, but when it is, I'll be sure to document it.