# Hyprland: a compositor you compile, and the wiki you need

> A tiling Wayland compositor written with no wlroots, kwin or mutter underneath it, which means it carries its own protocol code and its own build. The Makefile refuses to build by default, and the configuration lives in a wiki that moves with the project.

**hyprwm/Hyprland** — GitHub describes it as Hyprland is an independent, highly customizable, dynamic tiling Wayland compositor that doesn't sacrifice on its looks.. The repository metadata lists C++ as its primary language. The metadata lists the BSD-3-Clause license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/hyprwm/Hyprland
- Website: https://hypr.land
- Stars: 38,726 · Forks: 2,031
- Language: C++
- License: BSD-3-Clause
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/hyprwm-hyprland

## The default make target refuses to build anything

Compilation starts with a target that does nothing except send you to the documentation. The first target in the Makefile is `stub`, and running make with no arguments prints a message telling you not to run it without arguments and to refer to the wiki on how to compile Hyprland. Everything after that is real work. The `release` target is the one you want:

```bash
cmake --no-warn-unused-cli -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_INSTALL_PREFIX:STRING=${PREFIX} -S . -B ./build
cmake --build ./build --config Release --target all -j`nproc 2>/dev/null || getconf NPROCESSORS_CONF`
```

`PREFIX` is set to `/usr/local` at the top of the Makefile, and because the install prefix is a plain shell variable, moving where a compositor puts its binaries is a one-line edit rather than a packaging exercise. The tree holds no packaging directory, and the installation page linked from the front of the README lives on the wiki rather than in the repository. The consequence for a reader is that the repository alone does not tell you how to obtain a binary, and the wiki page it points at is the only route the project names. `make install` afterwards is a plain `cmake --install ./build`, and `make uninstall` reads `./build/install_manifest.txt`, so a tree you have deleted takes its uninstall list with it.

## make release generates the protocol sources before it links

The build is CMake with a makefile in front of it, and the order of operations is the interesting part. `make all` runs `clear` and then `release`, and `clear` does more than empty the build directory:

```bash
rm -rf build
rm -f ./protocols/*.h ./protocols/*.c ./protocols/*.cpp ./protocols/*.hpp
rm -f ./hyprctl/hw-protocols/*.cpp ./hyprctl/hw-protocols/*.hpp
```

Those protocol sources are generated rather than checked in, which is why the tree also carries a `subprojects/` directory and why `./protocols/` is treated the same way as build output. Two consequences follow for anyone building from git. An interrupted or half-cleaned checkout can leave you without generated headers, and the repair is a rebuild, not a file you can restore. And the build shape is a choice, not a constant: `debug` builds with `-DTESTS=true`, which brings in the `tests/` and `hyprtester/` code, while `nopch` adds `-DCMAKE_DISABLE_PRECOMPILE_HEADERS=ON`, the switch to reach for when the precompiled header path fails on your host. Pick the shape before the first build, not after a failure.

## No wlroots: the compositor carries its own protocol code

The project's own architectural claim is that it is 100% independent, with no wlroots, no libweston, no kwin and no mutter underneath it. You can read that in the layout. `protocols/` holds the Wayland protocol code, `src/` the compositor, `hyprctl/` the command line control tool, and `hyprland.pc.in` the pkg-config template that lets a build system find the result. The Special Thanks section credits wlroots for powering Hyprland in the past, which means the compositor moved off that base and now carries the protocol implementations itself. The project is BSD-3-Clause, with the LICENSE file at the root. What independence buys is direct authorship of the things on the feature list: custom bezier and spring curves, tearing support, window rules and the plugin surface. What it costs is a bill nobody else carries. When a Wayland protocol changes, the change lands here first, and no upstream library will have handled it for you.

## pluginenv is deprecated and installheaders wants a root prefix

Plugins are a first-class feature, with a built-in plugin manager in `hyprpm/` and layouts that plugins can supply, and the Makefile has targets for them. One of those targets no longer works. `make pluginenv` prints that it has been deprecated and exits with status 1, pointing you at `make all` followed by `sudo make installheaders`. The replacement has two gates in front of it. It checks for `./src/version.h` and stops if the file is missing, with a message telling you that you need to run `make all` first, and it writes into `${PREFIX}`, deleting the previous `include/hyprland` directory before recreating it and generating protocol headers with:

```bash
cmake --build ./build --config Release --target generate-protocol-headers
```

For a plugin author the cost is arithmetic. Plugin headers only exist after a full release build, they land in a shared system prefix, and the target removes that prefix on each run, so two checkouts built against the same `PREFIX` overwrite one another. The `example/` directory ships `hyprland.lua`, a `layouts/` folder and a `screenShader.frag`, so the shapes to copy are in the tree, but the plugin interface itself is described on the wiki, not here.

## Three releases of 0.56 landed inside three weeks

The project describes itself as fast and active and not afraid to provide bleeding-edge features, and the release tags bear that out. Version 0.56.0 was published on 2026-07-20, 0.56.1 on 2026-07-27 and 0.56.2 on 2026-08-05, and the last push to the main branch was on 2026-09-29. The same feature list pairs that cadence with something the project treats as a selling point: the config is reloaded instantly upon saving. Those two facts together define the trade. You get a compositor that picks up edits with no restart and features early, and you pay for it with a configuration that has to be re-read against each release, because a fast-moving project changes what a rule or a keybind means without announcing a format version. The bill arrives on dotfiles and on plugins, and the repository carries no compatibility statement for either. A `VERSION` file sits at the top of the tree, which at least gives you something concrete to record a config against.

## The feature list is a table of contents, not a specification

Read what the top of the project page does and does not contain. It lists gradient borders, blur, animations, glow and shadows, then window rules, monitor rules and layer rules, special workspaces described as scratchpads, window groups in a tabbed mode, tiling, pseudotiling, floating and fullscreen, fully dynamic workspaces, and per-workspace layouts. The layout list alone has six entries: Dwindle, Scrolling, Master, Monocle, a custom layout with Lua, and custom layouts with plugins. None of it is explained. There is not one keybind, one rule or one config example in that document. It links onward to a configuration wiki, a master tutorial and an installation page, and the substance lives there. The consequence is that this repository cannot serve as a reference for the configuration language, which is the single thing most people adopting a tiling compositor need from somewhere. The decision is therefore not whether the feature set is large. It is whether you are willing to keep your configuration against a wiki that moves with the project instead of against a document that stays put.

## A compositor, with no desktop in the repository around it

Hyprland is a compositor, and that word carries the practical meaning: it implements Wayland and does display server work, while the desktop around it belongs to somebody else. The top level of the tree has no panel, no file manager, no settings daemon and no display manager. What it has is `src/`, `hyprctl/`, `hyprpm/`, `hyprtester/`, `debug-tools/`, `protocols/`, `start/`, `docs/`, `example/`, `nix/`, `systemd/`, `tests/` and `scripts/`. The `example/` directory holds `hyprland.desktop.in` for a desktop entry, `hyprland.service` for a systemd unit, `launch.json` and a `swaybg@.service` template, which suggests a background setter driven through systemd. `hyprctl` and the socket-based IPC named in the feature list are how a script or an agent would drive the session, and `hyprland.pc.in` is what makes the whole thing findable from a build. So the answer to whether Hyprland is a desktop environment is no. Reaching a login screen with a status bar and a file manager is assembly work that starts only after the compositor itself runs.

## Conclusion

Hyprland fits someone who wants a tiling compositor they can rebuild, restyle and extend, and who is willing to track a configuration against a wiki that moves. It does not fit someone who needs a documented, versioned config format or a desktop that works on first login, since the repository supplies neither and points at the wiki for both. Before you commit, run a full release build from a clean checkout on your own machine, because the build generates its own protocol sources and that is where you learn whether your toolchain can produce them.

## FAQ

### What is Hyprland used for?

It is a dynamic tiling Wayland compositor, built to run windows in tiled, pseudotiled, floating or fullscreen arrangements with animations and window rules. Control comes through socket-based IPC and the hyprctl command line tool, and a built-in plugin manager in hyprpm/ extends it.

### Is Hyprland a DE or WM?

The project calls it a compositor, and the repository holds no desktop around it, with no panel, file manager or display manager in the tree. A session built on it means combining Hyprland with a bar, a launcher and a login manager that the project does not ship.

### how to install hyprland

The README sends installation to a wiki page and gives no package command of its own. From source, the Makefile's release target configures CMake with -DCMAKE_BUILD_TYPE:STRING=Release into ./build with PREFIX set to /usr/local, then cmake --install ./build puts it in place.

### how to use hyprland

The project links a master tutorial and a configuration wiki, and states that the config is reloaded instantly upon saving, so you edit and keep going without restarting the compositor. The repository itself documents no keybinds or rule syntax, so the tutorial is where the first session comes from.

### Which is better, the i3 or Hyprland?

The repository draws no comparison with i3. It states that it now runs with no wlroots, libweston, kwin or mutter underneath it, and credits wlroots, tinywl, Sway, dwl and Vivarium as projects it learned from rather than as alternatives it benchmarks against.

## Sources

- [Official documentation](https://hypr.land)
- [Official README](https://github.com/hyprwm/Hyprland#readme)
- [Project repository](https://github.com/hyprwm/Hyprland)
- [Release notes](https://github.com/hyprwm/Hyprland/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hyprwm-hyprland