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 or Flymake 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.