# dmd: the reference D compiler, and when to build it from source > DMD is the reference compiler for the D programming language, published by the dlang organisation under BSL-1.0. The repository is the compiler itself, not a packaged toolchain, and the README points to dlang.org for releases and the language specification. **dlang/dmd** — dmd D Programming Language compiler - Repository: https://github.com/dlang/dmd - Website: https://dlang.org - Stars: 3,315 · Forks: 722 - Language: D - License: BSL-1.0 - Published: 2026-09-24 · Updated: 2026-09-24 · Language: en - Canonical page: https://hysenlabs.com/projects/dlang-dmd ## What dmd is, and who the repository is actually for DMD is the reference compiler for the D programming language. That single sentence from the README is also the scope statement: this repository is where the compiler, the runtime and the surrounding test infrastructure live, and it is the definition other D compilers are measured against. The directory table in the README splits the tree into changelog, ci, compiler, druntime and a few smaller entries, with compiler/src holding the source code, build system and build instructions, and compiler/test holding the tests. That layout tells you who the repository is for. If you want to write D, the README sends you to dlang.org for releases, the language specification and other resources. If you want to change how D compiles, or fix a bug in the runtime, this is the place. The distinction matters because the two audiences need different things from the same page, and the README serves the second one first. The topics listed for the repository include compiler, dlang, dmd, fast, native and programming-language, plus hacktoberfest. The last one is a signal about contribution flow rather than about the compiler's design: the project participates in an event aimed at first-time contributors, which is consistent with a tree that carries a CONTRIBUTING.md and a CODEOWNERS file at the top level. ## How the compiler tree and the runtime tree relate The README describes compiler as the root of all compiler (DMD/frontend) related code and druntime as the root of all runtime related code. They are separate top-level directories with their own READMEs, and the top-level Makefile treats them as separate build targets. That split is the main architectural fact a newcomer needs: the frontend and the runtime are built and tested through different paths, even though a working D toolchain needs both. The top-level Makefile confirms this with distinct targets. One example builds the compiler unoptimized together with druntime; another runs the druntime tests; a third runs the compiler tests, which the comment notes involve a Phobos build. So a change in druntime and a change in the compiler are validated by different commands, and the compiler test path pulls in a standard library that lives outside this repository. The Makefile also shows the host compiler is pluggable. It resolves HOST_DMD from an explicit setting, falls back to the deprecated HOST_DC variable, then to DMD, then to whichever of dmd or ldmd2 is on the PATH. The examples go further and show building with an LDC host compiler via HOST_DMD=ldmd2, optionally with ENABLE_RELEASE=1 and ENABLE_LTO=1. A self-hosting compiler that can be bootstrapped by a different D compiler is a deliberate property, not an accident, and it is what makes the PGO path in the Makefile possible. ## Installing dmd and compiling your first D file The README does not give install steps for end users. It states that releases, the language specification and other resources can be found on the homepage at dlang.org, so that is where a packaged compiler comes from. What the README does give is the build path for the repository itself, and it assumes you already have a D compiler and dub. With both present, the README gives this one-line build: ```bash dub build dmd:compiler ``` The dub.sdl file at the top level and the dmd:compiler sub-package name are what make that target resolve. If dub is not your tool of choice, the Makefile is the other documented route, and its examples assume GNU make: ```bash make -j$(nproc) ``` That builds the compiler unoptimized and druntime. The Makefile notes that on FreeBSD the default make is not GNU make and you should install gmake and run it as gmake, and that on Windows you may need a prebuilt GNU make plus Git for Windows for bash and the common GNU tools. Once you have a compiler, the first real use is compiling a file with an ordinary dmd invocation, which is what the repository is building toward but is not shown in the README. Nothing in the README documents a rollback or uninstall path for a built compiler, so treat the build output as something you manage yourself. ## Building an optimized dmd, and what the Makefile warns about The Makefile is unusually explicit about the optimized paths, which is useful because a naive build of a compiler is slow to run. For a release build with an LDC host compiler it gives: ```bash make -j$(nproc) HOST_DMD=ldmd2 ENABLE_RELEASE=1 ENABLE_LTO=1 ``` And for the heaviest option, link-time optimization plus profile-guided optimization, it gives a single target that also builds druntime and Phobos as side effects: ```bash make -j$(nproc) HOST_DMD=path/to/ldmd2 dmd-pgo ``` The comment that matters most is the last one in that header block: use HOST_DFLAGS, not DFLAGS, for extra flags intended for the host compiler during the compiler build. Anyone who has set DFLAGS expecting it to reach the bootstrap step will have quietly built something other than what they intended. The Makefile also carries a deprecation warning for HOST_DC, which still works but is redirected to HOST_DMD. This is a build system that expects you to read it. The header points at compiler/src/build.d for the variables that affect the compiler build, and that file, not the top-level Makefile, is where the full set lives. There is no configuration file to edit and no environment variable list in the README itself. ## Where dmd is the wrong tool If you want to write D and ship something, cloning this repository is the wrong first move. The README's own direction is to dlang.org for releases, and the build instructions assume a host compiler already exists. Bootstrapping from source when a packaged compiler is available is work you do not need to do. The second case is more interesting. The repository is not a single artifact you can build once and forget. The compiler tests involve a Phobos build, and the dmd-pgo target builds druntime and Phobos as side effects. A contributor touching the frontend will end up building parts of the standard library, which means the change surface is wider than the directory name suggests. If your goal is a small, isolated patch, the test paths may be heavier than you expect. The third case is platform tooling. The Makefile assumes GNU make and, on Windows, a separate GNU make download plus Git for Windows for bash and tools like cp, mkdir, mv, rm, touch and which. On FreeBSD it tells you to install gmake and invoke it under that name. If your environment cannot provide those, the make route is not open to you, and the README does not describe an alternative for that situation beyond the dub command. ## dmd compared with LDC, and why the Makefile mentions it The Makefile's own examples answer the comparison question better than any summary could. It shows building dmd using LDC as the host compiler, with HOST_DMD=ldmd2, and the dmd-pgo target takes a path to ldmd2 in the same variable. LDC is a separate D compiler, and the dmd build treats it as a valid bootstrap compiler rather than a rival to be excluded. The difference in approach is visible in what each is asked to do here. dmd is the reference compiler, which is why the repository exists and why the language specification is published alongside it. LDC, in these examples, is used as a host: a compiler good enough to build the reference compiler, and one the Makefile is willing to run with LTO and PGO enabled. That is a statement about bootstrap quality, not about which compiler you should use for your own project. The README does not compare the two, does not recommend one for end users, and does not discuss code generation differences. ## Maintenance, releases and the licence file The repository is not archived, and the last push was on 2026-09-23, one day before this was written. Recent releases show a regular cadence: v2.113.0 on 2026-08-17, a release candidate v2.113.0-rc.1 on 2026-08-05, and v2.114.0-beta.1 on 2026-08-19. The pattern of a beta, a release candidate and a final release within a few weeks of each other is the upgrade cost in practice: if you track the compiler, you will see pre-release tags alongside stable ones, and you choose which to follow. For contributors, the changelog directory holds changelog entries for the upcoming release, and the README points to CONTRIBUTING.md for the bug-reporting guidelines. Nightly builds based on the current DMD and Phobos master branch are published under a dedicated nightly release tag, which is the mechanism for testing master without building it yourself. The licence is listed as BSL-1.0, and LICENSE.txt is at the top level. The README does not break down which files fall under which terms, and this is not legal advice: read LICENSE.txt and, if you are redistributing a built compiler or embedding the runtime, check the terms for the specific files you ship rather than relying on the repository-level identifier. ## Conclusion Adopt dmd if you are writing D and want the reference implementation, or if you are working on the compiler or druntime themselves. Do not clone this repository expecting a packaged toolchain: the README directs you to dlang.org for releases, and the build instructions assume an existing D compiler and dub. Before you start, confirm which host compiler you have (dmd, ldmd2 or gdmd), check the compiler/src README for the current build variables, and read LICENSE.txt rather than assuming BSL-1.0 covers every file in the tree. ## FAQ ### What is dmd used for? DMD is the reference compiler for the D programming language, and this repository holds the compiler and runtime source. The README directs people who want the compiler itself to dlang.org for releases and the language specification. ### Is D faster than C++? The README makes no performance comparison between D and C++. It lists fast among the repository topics and documents build options such as ENABLE_RELEASE and ENABLE_LTO for the compiler itself, but says nothing about generated code versus C++. ### How do I install dmd? The README does not give user install steps; it points to dlang.org for releases. To build the compiler from this repository instead, the README requires a D compiler and dub and gives the command dub build dmd:compiler. ### Can I build dmd with a compiler other than dmd? Yes. The Makefile resolves HOST_DMD from an explicit setting or from whichever of dmd or ldmd2 is on the PATH, and its examples show building with an LDC host compiler via HOST_DMD=ldmd2. ### What does this repository contain besides the compiler? The README lists changelog, ci, compiler and druntime as the main directories, with compiler/src holding source and build instructions, compiler/test holding tests, and compiler/ini holding predefined dmd.conf files. ## Sources - [dlang/dmd on GitHub](https://github.com/dlang/dmd) - [License: BSL-1.0](https://github.com/dlang/dmd/blob/master/LICENSE) - [Project website](https://dlang.org) - [README](https://github.com/dlang/dmd/blob/master/README.md) - [Releases](https://github.com/dlang/dmd/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dlang-dmd