remake: GNU Make with a debugger attached

A patched make rather than a new build tool

The positioning of this project is unusual and worth stating plainly before the feature list. remake is not a competing build system. The README says the sources here are patched GNU Make 4.3 sources, and the project description calls it enhanced GNU Make.

That distinction determines the whole adoption story. A makefile that works today keeps working, because the dependency graph semantics, the automatic variable expansion, the pattern rules and the shell invocation are still GNU Make. What you add is a set of commands and a debugger layered on top of a program you already know. For a team with a decade of makefile muscle memory, that is a much smaller change than migrating to a declarative build tool, and a much larger change than adding a few shell functions to your Makefile.

The added surface covers improved error reporting, tracing, target listing, graph visualization and profiling, and the package also contains a debugger. The documentation is hosted on ReadTheDocs with a features page and an installation page, and there is a wiki with developer information and video links.

The topic tags reflect the same emphasis: debugger, makefile, profile, trace and visualization. Anyone who has stared at a makefile wondering which of forty rules actually fired is the audience here.

The five commands that change how a build looks

The README illustrates the feature set through screenshots, and the option names are the clearest description of what each one does.

The `--tasks` feature lists the targets a makefile defines, which is the answer to the question of what you can actually build. The `--trace` feature, whose short option is `-x`, prints the commands as they run. Stock make has `-n` for a dry run, but the trace here is the interactive, readable version of what is happening rather than a single dumped list.

The `--show-parent` feature, short option `-c`, shows which makefile or target a rule came from. This matters more than it sounds. In a large makefile with included fragments, a rule that fires unexpectedly usually comes from a file you did not know was included, and the parent display is the fastest way to find out.

The `--profile` option produces profiling output, and the README shows it being displayed via KCachegrind, which is a familiar format for anyone who has looked at a C call graph. Profiling a build is unusual but genuinely useful: a build that takes eight minutes because one recipe recompiles a large source tree by hand is a real cost, and this makes it visible.

Graph visualization completes the set. The combination means you can go from a graph of the dependency tree, to a list of tasks, to a trace of a run, to a profile of where the time went, without leaving the tool.

The debugger is the reason the project still exists

The debugger is what distinguishes remake from a set of reporting conveniences, and it explains why the project is hosted under the Trepan-Debuggers organization rather than as a general make fork.

The value is in the failure mode that ordinary make handles badly. When a makefile fails, GNU Make prints the recipe that failed and stops. There is no way to look inside a recipe, no way to evaluate a variable at the point of failure, and no way to single out the rule that misbehaves. For a build of any size, the diagnosis is usually a process of elimination using added echo statements, and each iteration costs a full build.

A debugger attached to make changes that, because you can stop at a rule, inspect the state, and continue. The README links the debugger documentation separately from the features page, which suggests it is treated as a component of its own rather than a mode of the tracing features.

The branch structure reinforces the point that this is a long lived fork with a specific lineage. The default branch here is remake-4-4, and the README lists separate branches for patched GNU Make 4.2, 4.1, 3.82 and 3.81. Each version of make has its own branch, and the debugger presumably tracks the internal structures of each. That is a maintenance cost that only makes sense if the debugger is the product, which it is.

Building from source, since there is no package manager story

The README does not document an installation command. It points to the readthedocs installation page and to INSTALL-from-source.md in the repository, and the presence of configure.ac, acinclude.m4, autogen.sh, Makefile.am and a build-aux directory tells you this is a standard GNU autotools project.

The autotools layout is what a C project of this vintage uses, and it means the build is a configure and make cycle rather than a package manager install. The repository also carries a Rakefile, which is a Ruby build helper alongside the autotools path, and a rpm directory for packaging, plus a po directory for translations.

The two documented download routes are the SourceForge project page, which the README links with a download badge, and the GitHub repository itself. The repology badge in the README suggests the project is packaged for at least some distributions, and the SourceForge file path referenced points at a 4.3+dbg-1.5 build.

For someone evaluating this, the practical step is to compile it before reading further, because a source build is where you find out whether the toolchain on your machine still works with a codebase of this age. The unittest directory, the tests directory and the .travis.yml file show that testing infrastructure exists, and the .pre-commit-config.yaml at the root suggests the recent commits go through automated checks.

Where the version drift bites

The release history is the weakest part of this project, and it is worth reading the dates carefully.

The listed releases are remake-4.3+dbg-1.6 from 2022-01-22, release_4.3+dbg-1.5 with the nickname Pig Boy from 2020-03-15, and release_4.2.1+dbg-1.5 from the same day, which the release note describes as a 4.3 backport to 4.2.1.

So the newest tagged release is more than four years old, while the last push to the repository was on 2026-09-29 and the default branch is remake-4-4, one major version past the 4.3 that the latest release was cut from. The repository is not archived, so work is clearly still happening, but that work sits on a branch whose corresponding release tag is not in the list. Anyone building from a release tarball gets 4.3 with the debugger, and anyone building from the branch gets something newer and untagged.

The naming convention is itself informative. The version string combines the GNU Make version with a debugger version, using a plus sign, and the branch names follow the make version they patch. A fork that tracks an upstream tool by version has a recurring maintenance obligation: when GNU Make 4.4 lands, the fork has to re-apply its patches, and there is no guarantee the debugger survives that rebase intact.

The homepage points at bashdb.sf.net/remake, which reflects the project history, since this debugger descends from the bashdb work. The topics list includes visualization, and the screenshots directory holds the images used in the README.

How this compares to fixing the makefile

The honest alternative to adopting remake is to not use it and instead fix the build, and for a lot of teams that is the right call.

If the problem is that you cannot tell what a build is doing, stock GNU Make already has options. The `-n` dry run prints commands without executing them, `--debug` prints a good deal of reasoning about why each target was rebuilt, and adding `-d` or a `$(info ...)` line gives you targeted visibility. The `--profile` capability here is genuinely harder to reproduce, since GNU Make has no built-in profiler, but a wrapper script that times each recipe is not hard to write.

The debugger is the harder capability to replace. A make-aware debugger, one that understands that a variable expansion failed and why, is not something you can approximate with a shell debugger or a printf. So the case for remake rests on the debugger, and the case against it is that it is a fork you have to build and track.

There is a third path worth naming: change the build system. For a project with a small makefile, the effort of debugging make may exceed the effort of moving to something declarative where the dependency graph is explicit and the failure mode is a missing rule rather than an opaque recipe. That is a large change, and remake is the option for people who want the improvement without that change.

The GPL-3.0 licence is worth noting for a distribution context. If you only use remake as a build tool on your own machine, the licence is not a practical constraint. If you plan to ship it inside a product or a toolchain image you distribute, the copyleft obligations of GPL-3.0 apply to the distributed work, and that is a conversation to have before you build it into a release artifact.

Editorial conclusion

Adopt remake if you maintain large makefiles and want to see what a recipe really does, step through a failing target, or profile where a build spends its time, and you are comfortable compiling from source. Do not adopt it for a new project, because the answer to a slow build in 2026 is not usually a patched make, and the release line has not moved since 2022. Verify first that your makefile works with stock GNU Make 4.3, that the debugger branch you need matches your make version, and that a source build succeeds on your toolchain before you point a critical build at it.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. Trepan-Debuggers/remake on GitHub