Eldev (Elisp development tool) is an Emacs-based build tool, targeted solely at Elisp projects. It is an alternative to Cask. Unlike Cask, Eldev itself is fully written in Elisp and its configuration files are also Elisp programs. If you are familiar with Java world, Cask can be seen as a parallel to Maven — it uses project description, while Eldev is sort of a parallel to Gradle — its configuration is a program on its own.

• Eldev configuration is Elisp. It can change many defaults, add special cases for Emacs versions and much more — even define additional Eldev commands and options.

• Built-in support for regression/unit testing.

• Blends nicely into continuous integration setups.

• Can run on different Emacs version even on the same machine; can also use Docker for that.

• There are four levels of configuration — you can customize most aspects of Eldev for your project needs and personal preferences.

• Project dependency downloading, installation etc. is fully automated, you only need to specify which Elisp package archive(s) to use.

• You can also use local dependencies, even those that don’t use Eldev (some restrictions still apply). This is similar to Cask linking, but with more flexibility.

• Full support for autoloads during development.

• Miscellaneous operations useful during development: running Emacs with only your project, linting source code, evaluating expressions in project’s context, profiling.

• Can automate release process for your project.

• Eldev by default isolates your project for development, helping you to distinguish between problems with setup or configuration and inherent bugs in the project.

• Full-featured build system for complex projects.

• Can help you debug your code.

• Runs on all major operating systems: Linux, macOS, Windows.

• Eldev is fast.

Eldev source code itself comes with no examples, but there is a short list of real-world projects in the documentation.

The easiest and most common way to install Eldev on Linux, macOS, etc. is this shell oneliner:

This will install eldev script to ~/.local/bin. Usually, this directory should already be in your PATH. But if not, e.g. in ~/.profile add this:

Documentation lists several other ways to install Eldev, including on Windows. They are not more difficult than the one above.

Like many (if not most) other development tools, Eldev is unsafe when executed on untrusted code. For example, simply running eldev in a project you have just downloaded from hackerden.org can result in anything, including emptied home directory. For that matter, running make or gradle is not better in this regard. Eldev is perhaps a bit more dangerous, because even eldev help reads file Eldev, thus executing arbitrary code.

Even seemingly harmless things, like opening a .el file in Emacs can lead to unforeseen consequences. If you e.g. have Flycheck enabled everywhere, this will result in byte-compiling said file, which also can execute arbitrary code, for example using (eval-when-compile …​) form. The same holds for installing (not even using!) Elisp packages.

Only use build tools on code that you trust. Better yet, don’t even touch code that you don’t plan running.

Eldev comes with built-in help. Just run:

This will list all the commands Eldev supports. To see detailed description of any of those, type:

In the help you can also see lots of options — both global and specific to certain commands. Many common things are possible just out of the box, but later we will discuss how to define additional commands and options or change defaults for the existing.

Two most important global options to remember are --trace (-t) and --debug (-d). With the first one, Eldev prints lots of additional information about what it is doing to stdout. With the second, Eldev prints stacktraces for most errors. These options will often help you figure out what’s going wrong without requesting any external assistance. Also check out section on various debugging features discussed later.

Eldev mostly follows GNU conventions in its command line. Perhaps the only exception is that global options must be specified before command name and command-specific options — after it.