2

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.

Ian Bryant
  • 21
  • 2
  • 3
    [Emacs Lisp is pretty bad outside of Emacs](http://www.lunaryorn.com/2014/08/12/emacs-script-pitfalls.html). – wasamasa May 05 '15 at 08: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 May 05 '15 at 08: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. – Jordon Biondo May 05 '15 at 13:30
  • I'm looking at the --script option as being starting point: http://www.gnu.org/software/emacs/manual/html_node/emacs/Initial-Options.html#Initial-Options -- "Run Emacs in batch mode, like ‘--batch’, and then read and execute the Lisp code in file." – Ian Bryant May 05 '15 at 13:50

2 Answers2

4

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.

wvxvw
  • 11,222
  • 2
  • 30
  • 55
  • 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 (http://stackoverflow.com/questions/10210742/run-elisp-program-without-emacs/10211087#10211087), then my efforts might be useful to others outside the Emacs user base. I hope :-) – Ian Bryant May 05 '15 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 May 05 '15 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 May 05 '15 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 May 05 '15 at 16:54
  • what do you think about gradle? – chen bin May 07 '15 at 11:58
  • @chenbin Afraid to drive this conversation too much off-topic, I'd say that if you were coming from Java world, where all you knew is Ant (Ivy) and Maven, then Gradle is an improvement. It's easy to do general programming in it (things like strings manipulation in Ant are a nightmare). It's easy to extend. Compared to other Java tools it has less boilerplate. You can write reusable build modules (shared between different projects). But it is bad at being a build system :) everything it does is half-baked and needs a layer of duct tape. Some things in its core are fundamentally wrong. – wvxvw May 07 '15 at 13:13
  • Results caching is based on a SHA taken of an entire file, and if the file is huge (which binaries tend to be), computing this hash may take longer than to compile the project again. No alternative mechanism (you must roll your own, if you want to make it usable). Trying to create project description dynamically is a kludge, with so many pitfalls that in the end you wish you used something else. The documentation is full of boasting and self-promotion, which makes the ratio of signal to noise very low. I could go on for longer, but this really isn't a good place for it :) – wvxvw May 07 '15 at 13:18
  • Thanks. I will mark your comment. btw, I'm actually coming from c++ world. – chen bin May 08 '15 at 10:23
  • I'm just thinking about the SHA gradle thing, in Linux you could use tmpfs, so place your project into tmpfs should improve the performance of gradle. See my script at http://blog.binchen.org/posts/emacs-speed-up-1000.html , modify the script and you can use it to manage general java projects. – chen bin May 08 '15 at 13:08
  • @chenbin wrt the script: does it make the configuration read-only in this case? Why do you think it improves performance other than that used for I/O? That seems hack-ey, wouldn't increasing file-system cache do the same? In where it concerns Gradle, I'm afraid that's not a scalable approach... I mean, you don't want to permanently store the binaries from the last build in memory only to speed up Gradle's start time... that memory may have other good uses too. Besides, Java has its own canon-caches, or w/e it's called to cache filesystem queries... which still isn't helping much. – wvxvw May 08 '15 at 13:30
  • In any case, taking a hash of a file is an overkill, and eventually, it generates false positives. It's much better to invest some time into version control interface to figure out what actually changed. A common problem with build systems is that they don't notice when there are extra files. Hashing doesn't solve this problem. – wvxvw May 08 '15 at 13:33
  • Configuration is still writable. I've got 24G memory. – chen bin May 11 '15 at 12:03
1

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 May 08 '15 at 00:58