Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
qBittorrent version and Operating System
Latest/recent master, Ubuntu 18.04
If on linux, libtorrent-rasterbar and Qt version
libtorrent 1.2.3, Qt 5.9.5
What is the problem
Current CMake build scripts have a few problems:
What is the expected behavior
Better support for building with CMake, including the possibility of building without GUI via defining
Steps to reproduce
Example of the above:
mkdir build && cd build cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug -DDISABLE_GUI:BOOL="1" ..
Extra info(if any)
I read through #11038, so I know there are rather strong feelings about CMake adoption.
CMake is now by far the most used build system for C++ projects, and is now even going to become the default for Qt.
Since CMake is more widely used than qmake+autotools, there is a bigger chance that more people can contribute to improving the build scripts. More and more resources around the web focus exclusively on modern systems like Meson and CMake. CMake has good cross platform support, including Windows (I'm not a Windows developer, but the overall consensus seems to be that CMake is the superior alternative to autotools) and niceties like an PPA for the most recent versions on Ubuntu.
As a side note, libtorrent also has good support for building with CMake.
As far as the extra
Both options are possible, but the effects are slightly different. From the cmake manpage:
-D <var>:<type>=<value>, -D <var>=<value> Create or update a CMake CACHE entry. When CMake is first run in an empty build tree, it creates a CMakeCache.txt file and populates it with customizable settings for the project. This option may be used to specify a setting that takes priority over the project’s default value. The option may be repeated for as many CACHE entries as desired. If the :<type> portion is given it must be one of the types specified by the set() command documentation for its CACHE signature. If the :<type> portion is omitted the entry will be created with no type if it does not exist with a type already. If a command in the project sets the type to PATH or FILEPATH then the <value> will be converted to an absolute path. This option may also be given as a single argument: -D<var>:<type>=<value> or -D<var>=<value>.
You can use the CMake GUI to easily check the default values for stuff like
Our previous setup lead to two unintended consequences: * Debug flags were included in both release and debug builds instead of just debug builds * Clang doesn't support -gX (where X is the level of debugging optimization), but we checked for -Og support instead This commit avoids both of these scenarios by removing the additional flags altogether. Partial resolution to qbittorrent#11856.
I hadn't seen this comment, but good insight. I still heavily prefer the simplicity of -DDISABLE_GUI as it stays inline with -DDISABLE_WEBUI, and if you leave it enabled, you simply don't pass the flag. I'm probably going to do some more work with our build system this weekend to address that first point.
So digging deeper into it, passing -DDISABLE_GUI will still disable some code compilation as actual source files check against that flag but our CMake configuration would likely error out if not scream at us. You can pass -DCMAKE_DISABLE_FIND_PACKAGE_Qt5Widgets=ON to explicitly disable the GUI as we do in travis, which is a little crazy for end-users and downstream. I understand the reasoning behind the revamp and swap to Qt5Widgets_FOUND, but it just makes a more confusing scenario for end-users and downstream.
If @zeule is still around, what are your thoughts on swapping back to a simple DISABLE_GUI check?