# Clementine Music Player: A Qt Library Organizer You Build From Source > Clementine is a GPL-3.0 music player and library organizer for Windows, Linux and macOS, written in C++ with Qt. Its README is short, its release tags are commit-style, and the real work happens in CMake. **clementine-player/Clementine** — :tangerine: Clementine Music Player - Repository: https://github.com/clementine-player/Clementine - Website: https://www.clementine-player.org/ - Stars: 4,256 · Forks: 730 - Language: C++ - License: GPL-3.0 - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/clementine-player-clementine ## What Clementine Solves, and for Whom Clementine is a desktop music player that also manages a music library. The README describes it in one line as "a modern music player and library organizer for Windows, Linux and macOS", and the repository's topics list confirms the same three platforms plus Qt and C++. That is the scope: a native desktop application, not a server, not a web player, not a streaming service client. The audience follows from the build instructions. The README's only installation path is compiling from source with git, cmake and make, and it defers the dependency list to the project Wiki. So the project is aimed at people comfortable with a C++ toolchain, or at users whose distribution or platform already ships it. If you want a player you install from a store page and never think about again, the README does not describe that route at all. The library-organizer half is the part that distinguishes it from a bare audio player. The README does not enumerate library features, so treat the phrase "library organizer" as the project's own summary rather than a specification. The Changelog is where the README sends you to check whether a feature already exists, which implies the feature set has moved over time and is not fully described on the front page. ## How the Build Mechanism Actually Works The repository layout tells you more about the architecture than the README does. There is a top-level CMakeLists.txt, a bin/ directory, a cmake/ directory with helper modules, a 3rdparty/ directory, and a gst/ directory. The README's build sequence changes into bin/ before running cmake, which means bin/ is the intended out-of-source build directory, not a directory of checked-in binaries. Running cmake .. from inside bin/ generates the build system one level up, and make then compiles there. The presence of gst/ alongside src/ is the clearest architectural signal in the listing: multimedia playback is delegated to GStreamer rather than implemented inside the application. That is a design decision with consequences. It means playback behavior depends on the GStreamer version and plugins present on the host, not solely on the Clementine build. It also means a codec that GStreamer cannot decode is not something Clementine can fix on its own. The 3rdparty/ and ext/ directories suggest bundled or vendored dependencies, while Brewfile indicates a macOS dependency path and Toolchain-mingw32.cmake indicates a cross-compilation target for 32-bit Windows. The debian/, snap/, dist/ and fastlane/ directories show packaging and distribution scaffolding for several targets. None of this is explained in the README, which is the main documentation weakness: the repository structure is informative, but you have to read it yourself. ## Installing Clementine From Source: A First Build The README gives exactly one installation recipe. It is a clone followed by a CMake build, and the dependency list lives in the Wiki rather than in the repository. Start by getting the code: ```bash git clone https://github.com/clementine-player/Clementine.git && cd Clementine ``` That command creates a Clementine directory and moves you into it. Nothing is compiled yet. Next, change into the bin directory, configure with CMake, compile, and install: ```bash cd bin cmake .. make -j$(nproc) sudo make install ``` The README presents these as four separate steps in that order. cmake .. reads the top-level CMakeLists.txt and generates build files inside bin/. make -j$(nproc) compiles in parallel using all available cores, and sudo make install copies the result into system locations. If cmake fails, the missing piece is almost certainly a dependency, and the README's answer is to consult the Wiki page it links for "more instructions and a list of dependencies". There is also a cmake_uninstall.cmake.in file at the top level, which implies an uninstall target exists in the generated build system, but the README never mentions it. That is a documentation gap worth knowing about before you run sudo make install. The README also does not name a version, a minimum CMake version, or a required compiler, so the Wiki is not optional reading. ## Release Tags That Are Not Version Numbers The three most recent releases are tagged 1.4.1-150-g126edd142, 1.4.1-148-gc8c134cae and 1.4.1-147-ge619885d6, dated 2026-09-22 and 2026-09-23. That format is git describe output: a base tag, a commit count since that tag, and an abbreviated commit hash. Two consequences follow. First, these are builds off a development line, not numbered stable releases. The base is 1.4.1, but the tags themselves are 150, 148 and 147 commits past it. Anyone who needs to cite a version number in a bug report has to decide whether to cite 1.4.1 or the full describe string, and the README's bug template asks for the "Clementine version" without saying which form it wants. Second, the spacing is tight. Three releases appear within roughly two days, which is consistent with continuous publishing rather than a release cadence. The README's bug guidance tells reporters to "try the latest build" from the releases page before filing, and that advice only makes sense against this kind of tag flow. If you pin to one of these tags, expect the next one to look different and to carry more commits than the number suggests at a glance. The README does not document a rollback path to an earlier tag. ## Where Clementine Is the Wrong Choice The README is honest about its own limits by omission. It documents no rollback, no downgrade, and no way to revert an install performed with sudo make install. If you are deploying to machines you cannot easily rebuild, that is a real gap: the uninstall target implied by cmake_uninstall.cmake.in is not described anywhere in the README, so you would be discovering it from the build system rather than from documentation. Dependency management is the second failure mode. Because the README pushes dependencies to the Wiki and the repository carries a 3rdparty/ directory, a Brewfile and a MinGW toolchain file, the build surface differs per platform. A successful build on one machine says little about another. And because playback runs through GStreamer, a missing plugin shows up as a playback failure rather than a build failure, which makes the problem harder to attribute. Finally, if you need a headless player, a service, or something scriptable through a documented API, nothing in the README suggests Clementine is that. It is a desktop application for Windows, Linux and macOS with a graphical library organizer. Treat anything outside that description as unsupported. ## Clementine Compared With a Command-Line Player The clearest alternative category is the terminal music player, of which the common example is mpd with a client such as ncmpcpp. The difference is not cosmetic. Clementine builds a Qt desktop application with a graphical library organizer; mpd is a daemon with a client protocol, so it can run headless on a server and be driven from any machine on the network. Clementine's README describes a desktop program for three operating systems, with no daemon mode mentioned. The dependency story differs too. Clementine's README points to a Wiki dependency list and the repository vendors code under 3rdparty/, which means a Qt and GStreamer stack plus whatever else the Wiki lists. A daemon-style player typically has a narrower dependency set because it has no GUI toolkit. If your constraint is a minimal container or a machine without a display server, the daemon approach fits and Clementine does not. The trade-off runs the other way as well. A daemon player gives you no library organizer unless you add a separate client, and the client experience varies. Clementine's own README frames the library organizer as part of the product, which is the thing a bare daemon does not provide. Choose based on whether you want the GUI and the library in one process or a headless core you attach clients to. ## Licence, Upgrade Cost and What Maintenance Looks Like Clementine is GPL-3.0, and the top-level COPYING file is the licence text. For anyone linking against it or redistributing a modified build, that is a copyleft licence, so the obligations attach to distribution rather than to private use. This is a description of the licence identifier, not legal advice; read COPYING and, if you are redistributing, get proper counsel. The upgrade cost is tied to the build-from-source path. Because the README's install is git clone plus cmake plus make install, moving to a newer build means repeating the same sequence against a newer tag, and the README documents no in-place upgrade procedure. Each upgrade also re-runs the dependency check implicitly, since a new build may need something the Wiki lists that your machine does not have. The repository is not archived, and the last push was on 2026-09-23, the same day as the newest release tag. That is a fact about recency, not a quality claim. What it tells you is that the tag stream is live and that pinning to a specific describe-style tag is a deliberate choice rather than a default. The Changelog at the top level is the file the README tells you to consult before requesting a feature, and it is the practical place to check whether an upgrade is worth the rebuild. ## Conclusion Adopt Clementine if you want a GPL-3.0 Qt desktop player whose entire build path (git clone, cmake .., make) is documented in the README and whose tags are visible in the releases list. Do not adopt it if you need a documented rollback procedure, a tagged stable version number, or a package-manager install path: the README points to the Wiki for dependencies and gives no uninstall or downgrade instructions. Before committing, verify that your distro or platform can satisfy the Wiki's dependency list, then check the Changelog for the feature you need and confirm the newest release tag is one you are willing to build. ## FAQ ### How do I install Clementine on Ubuntu or Linux Mint? The README gives one path for all Linux distributions: clone the repository, then run cmake .. and make -j$(nproc) inside bin/, followed by sudo make install. It does not list distribution packages, and it points to the project Wiki for the dependency list you need before cmake will succeed. ### How do I install Clementine on Windows? The README states Clementine targets Windows but gives no Windows-specific install steps, only the git clone and CMake build sequence. The repository does contain a Toolchain-mingw32.cmake file, which indicates a MinGW cross-compilation target, and the README directs you to the Wiki for further instructions. ### How do I use the Clementine music player? The README describes Clementine as a music player and library organizer for Windows, Linux and macOS, and lists a website and GitHub page as the main references. It does not walk through the interface, so the README itself is not a usage guide. ### How do I install Clementine on Arch Linux? The README does not give Arch-specific instructions. Its only documented install path is the generic one: git clone the repository, then run cmake .. and make -j$(nproc) inside bin/, followed by sudo make install, with dependencies listed on the project Wiki. ### How do I install Clementine on Linux Mint? The README treats Linux as one target and offers no Mint-specific steps. You would follow the same clone-and-CMake sequence it documents for all platforms and satisfy the Wiki's dependency list first. ## Sources - [clementine-player/Clementine on GitHub](https://github.com/clementine-player/Clementine) - [License: GPL-3.0](https://github.com/clementine-player/Clementine/blob/master/LICENSE) - [Project website](https://www.clementine-player.org/) - [README](https://github.com/clementine-player/Clementine/blob/master/README.md) - [Releases](https://github.com/clementine-player/Clementine/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/clementine-player-clementine