dwm-flexipatch uses preprocessor directives to select patches

What makes this different from patching dwm

dwm is distributed as a single C file, and the traditional way to change it is to download a patch and apply it with `patch`. That workflow is why dwm has a reputation for being difficult to try: every patch is a diff against a specific upstream state, and they interact badly.

dwm-flexipatch takes a different approach. It uses preprocessor directives to decide whether or not to include a patch during build time. The consequence, stated plainly in the README, is that the build contains both the patched and the original code.

The toggle is a single line. To include the `alpha` patch you flip a setting in `patches.def.h`:

#define BAR_ALPHA_PATCH 1

That is the whole user interface for enabling a feature. You edit a header, recompile, and the feature is either in or out.

The upside is exactly what the README claims it is. If you have been curious about dwm but discouraged by manual patching, this shows what a fully fledged dwm looks like without committing. And once you have found what works for you, you are in a better position to choose patches if you later decide to start patching from scratch.

The cost is that some patches are no longer optional

The tradeoff is stated just as directly. Due to the complexity of some of the patches, dwm-flexipatch has diverged from mainstream dwm by making some core patches non-optional for maintenance reasons.

The changelog shows where that happened, and it is worth reading as history rather than as a feature list. In August 2020 the project added logic to auto-hide bars when nothing is drawn on them, added a clientindicators patch, unified the indicator code, and simplified Pango integration by settling on common function signatures. A day earlier, colour configuration was simplified and a set of colour schemes was shared between multiple patches, which made `urgentborder`, `floatborder` and `titlecolor` non-optional.

So the boundary between optional and required is not a policy decision made once. It erodes as patches come to share code. That is the maintenance cost stated honestly rather than hidden.

There is a branch for the alternative. The README points to `dwm-flexipatch-1.0` for the classic build, where building with no patches selected gave something more or less identical with mainstream dwm. That branch is described as subject to bug fixes and mainstream dwm updates as far as feasible.

If you want to understand dwm itself rather than a curated feature set, that branch is the more honest starting point.

Stripping the code you did not select

The project solves the consequence of its own design with a separate tool. If you have found the patches you want but do not want the rest of the flexipatch entanglement, the README points at `flexipatch-finalizer`, a custom pre-processor tool that removes all the unused flexipatch code, leaving a build that contains only the patches you selected.

That is a two-stage workflow: use flexipatch to explore, then finalise once you have decided. It is also an admission that the exploration build is not the build you want to run.

The patch catalogue is large and additive rather than curated. Recent entries include the dragfact patch on 2026-05-17, movecenter on 2025-10-30, games on 2025-09-21, banish on 2025-06-27 and always on top on 2025-06-15. Before that come xresources, border rule, a variant of the launcher, placedir, do-not-die-on-color-allocation-failure and a long tail down to 2020. Entries are occasionally removals rather than additions, for instance alwaysfullscreen removed in March 2021 because it had been merged into dwm 6.2.

Some entries are behaviour changes rather than features. In April 2021 a vanitygaps patch replaced smartgaps with smartgaps_fact, allowing gaps to be disabled or increased when there is only one client. And the dwmblocks upgrade for statuscmd changed the signalling mechanism from SIGUSR1 to SIGRTMIN, with a compatibility option to switch back, and changed the configuration as well.

What the build actually does

The Makefile shows how the configuration is wired, and the interesting part is the dependency line.

${OBJ}: config.h config.mk patches.h

patches.h:
	cp patches.def.h $@

`patches.h` is generated by copying `patches.def.h`, and every object file depends on it. The same pattern applies to `config.h` from `config.def.h`, which is upstream dwm's convention.

The source list is `drw.c dwm.c util.c`, with `transient.c` present in the tree and a `patch/` directory alongside. There is a conditional: if `YAJLLIBS` is defined, the build also produces `dwm-msg` from `patch/ipc/dwm-msg.c`, and the install target copies it alongside the binary and the man page.

The install target also handles the two files a desktop session needs. It writes the manual page by substituting `VERSION` into `dwm.1` with sed, and it places `dwm.desktop` into `share/xsessions` only if the file is not already there, using a test before the copy.

There is a portability note for FreeBSD users in the comments: prefix all `ifdef`, `else` and `endif` statements with a dot so the Makefile parses there.

The repository is based on dwm 6.8 at commit 2bb919e dated 2026-03-08.

Navigating the patches, and project status

The README offers two navigation aids, and one of them is unusual. There is a map of patches, a diagram that tries to organise the patches into categories, hosted as a Coggle diagram. For a repository with this many optional features, a diagram that shows relationships between them is genuinely more useful than a flat list.

There is also a Known Issues discussion category, which is where a project of this kind should send people who hit a bug, since the interaction between patches is the usual cause.

The underlying dwm documentation at dwm.suckless.org remains the reference for what dwm is, how to install it and how it works. This project is a fork, not documentation.

On status: the last push was on 2026-07-06 and the repository is not archived. There are no GitHub releases. The default branch is master, and the licence is MIT with a LICENSE file at the root.

One practical caution for anyone arriving from an older guide: the 2020-07-18 changelog entry records the decision that future versions may diverge from mainstream dwm by making some patches non-optional. Guides written before that date will describe a build that no longer behaves the way they describe.

Editorial conclusion

Adopt dwm-flexipatch if you want to evaluate many dwm patches at once before committing to any of them, since toggling a define and recompiling is faster than applying and reverting diffs. Do not adopt it as a minimal base if you care about what ends up in the binary, because unused patch code stays in the source and a separate finalizer tool is needed to strip it. Verify first which branch you are on, because master has diverged from mainstream dwm with non-optional patches while dwm-flexipatch-1.0 keeps the classic behaviour.

Frequently asked questions

Official sources

1. bakkeby/dwm-flexipatch on GitHub
2. Issues
3. License: MIT
4. README