I'm building a new appliance, linking BusyBox with Tor on top of a minimal GNU/Linux operating system. I'd like to try something different for the automated build infrastructure with this one and Emacs Lisp has been calling me lately.

Do you have a project written in C that uses automated build scripts written in Elisp? Guile might might be a runner-up but I need to get up-to-speed quickly on the infrastructure needed, so I'm hoping for Elisp for familiarity's sake.

  • 3
    Emacs Lisp is pretty bad outside of Emacs.
    – wasamasa
    Commented May 5, 2015 at 8:17
  • 1
    @wasamasa, it's faster to start a new Emacs instance then to get a Clojure REPL running. So by that metric, it's better than Clojure.
    – abo-abo
    Commented May 5, 2015 at 8:19
  • 1
    I disagree with the blanket statement of "Emacs Lisp is pretty bad outside of Emacs", I have had good experiences developing build tools for projects in elisp. I have done a build/deployment tool and a parameterized report builder tool with elisp. I do recommend anyone look elsewhere first, to see if there is a tool that does what they want already, but if building your own seems like a good choice, you might as well give Elisp a look. I wouldn't use elisp to try to build a reusable build system, but exploring its use on build scripts for very unique projects is not a terrible idea. Commented May 5, 2015 at 13:30
  • I'm looking at the --script option as being starting point: gnu.org/software/emacs/manual/html_node/emacs/… -- "Run Emacs in batch mode, like ‘--batch’, and then read and execute the Lisp code in file."
    – Ian Bryant
    Commented May 5, 2015 at 13:50

2 Answers 2


I had a similar idea once, but honestly? there are quite a few things that a proper build system needs, and which will require quite a lot of work. One thing you want is memorizing things you've built and building only the things you have to. This would typically call for interaction with database, version control system and writing code which builds a tree from the targets that you have and ensures that no change goes unnoticed. You would also want it to be multilingual, that is not specific to a programming language.

It seems like it's all possible to do inside Emacs, but it will be difficult to share it with other people who don't use Emacs. My experience with other build systems so far is that they create the largest amount of frustration the software can give to a programmer. This is because programmers see them as inessential thus rarely learn them well. On the other hand, the popular build systems are really, really bad :) To make this a little more concrete: for a year, I was responsible for my company's CI server, which ran a couple of build scripts, most of them written in Ant, some in Gradle and others used Fabric. Other programmers in the company really struggled with all of them. And that struggle was never over. Programmers could spend days trying to configure their Eclipse to build using Ant (something that seems trivial to me, but that's my job, so...) When I imagine same people trying to use Emacs for builds--oy-vey!

Bottom line: I don't think it's the editor's place to be also the build system, instead, it could be a much improved interface to a build system! For instance, displaying the hierarchy of the build tasks, examining the history, looking for stale outputs, navigation and housekeeping are all equally valuable.

  • I share your feelings about build systems. The proliferation of "build.sh" scripts is likely due to the need to sidestep the frustration that many build systems bring to the joy of making! However, I do need intelligence in my builds more than a "keystroke log" of basic build commands. If written right, perhaps executed from the shell rather than from within Emacs (stackoverflow.com/questions/10210742/…), then my efforts might be useful to others outside the Emacs user base. I hope :-)
    – Ian Bryant
    Commented May 5, 2015 at 14:02
  • @IanBryant if you want to write a build system in Lisp, I'd look for an embeddable Lisp. Many Scheme implementations are made to be embedded in other applications. ECL is an embeddable Common Lisp. They are easy to integrate with the program, they are quite a bit faster than ELisp, and embedding means that all you have to do for the user is to send them a binary of your build program, so that they don't have a chance to misconfigure it. There are lots of ways for the build script in ELisp to go wrong, for example, it will be executed by emacserver with lots of loaded packages.
    – wvxvw
    Commented May 5, 2015 at 16:11
  • Also, think about ELisp being technically, single-threaded, while being able to identify build targets which you can execute simultaneously is a huge bonus!
    – wvxvw
    Commented May 5, 2015 at 16:15
  • I see where you're going. Perhaps Guile is better suited. I am trying to keep my code base and tools all GNU, so that is why I am starting with Emacs Lips as my first option. The long term goal is the submit this project for consideration as an "Official GNU Project" so there's the constraint.
    – Ian Bryant
    Commented May 5, 2015 at 16:54
  • what do you think about gradle?
    – chen bin
    Commented May 7, 2015 at 11:58

I would not want to write build automation in a language with no simple script interface, no parallelism, primitive networking, no good facilities for external processes—you can't even pipe in Emacs Lisp—and zero integration into basically anything else.

YMMV, but to me that's basically the antithesis of what I'd want for build automation which is all about scripting, networking and calling external processes.

Emacs Lisp is a good language in its own way, and for its specific purpose, but I would not try to bend it for something it wasn't made for and is inherently poor at. The pain that I'd suffer from this choice on the long run isn't worth the temporary convenience of using this language—not that I'm a particular fan of Emacs Lisp anyway, but I think you get my point.

I'd use Python and Fabric, or Ruby and Rake, for the simple reason that these languages are frequently used for this purpose, so almost any problem that you can possibly find has already been solved before by someone else, which in turn means that you can spend less time on the boring task of build automation and spend more time on the real problem—unless build automation is your real problem, that is, but I don't hope so for your sake :)

TL;DR: No, and it never will.

  • I appreciate the feedback. Your pitfalls page was actually very helpful. Looks like a combination of Guile and Gawk is where I'm going, then. Maybe later when build automation is my real problem, I'll revisit this question and simply make Elisp work for me :-)
    – Ian Bryant
    Commented May 8, 2015 at 0:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.