Welcome, New Emacs Developers

Emacs switched the version control system from Bazaar to git yesterday, so now is the time to start hacking away at Emacs.

Emacs: The Best Thing Since Sliced Bread If It Wasn’t For The Fact That Emacs Was Actually Invented Before Sliced Bread.

This is a very short how-to guide on building and then contributing to Emacs.

Depending on what OS you’re running, you should install some libraries and stuff.  On Debian/Ubuntu you’d say something like

sudo apt build-dep emacs

(See the end of this post for instructions for other operating systems.)

Then you need to get the Emacs sources and build Emacs.  Here’s how on most Linux systems:

git clone git://git.savannah.gnu.org/emacs.git
cd emacs
make
./src/emacs &

And you’re off! If you know what you want to add to Emacs, just start hacking away. If not, you should have a look at the wishlist in the Emacs bug tracker.  Starting with a new feature can be less daunting than starting with a bug, since it’s more open ended.  And more fun.

First we need to get the bug tracker into Emacs.

M-x package-install RET debbugs RET

Ready for action!

M-x debbugs-gnu RET C-a C-k wishlist RET

debbugs3This will list everything that anybody wanted, but nobody got around to doing anything about.  Find one you think look interesting, hit enter to read more about it, and if you think you want to have a go, start hacking away.

debbugs4When you’re done, make a diff, reply to the bug report with F, and include the diff in the email.

Emacs requires a copyright assignment on all bits that are larger than 15 lines.  Send an email to copyright-clerk@fsf.org saying you wish to assign your Emacs code to the FSF, and they’ll get back to you on the paperwork, which is very un-daunting.

If you’re fixing lots of bugs and adding lots of new code, just ask for commit rights to the Emacs repository, and your code will fly out a lot faster.

Go forth and Emacs!

——————–

Appendix:

If apt-get build-dep doesn’t work for you on Debian/Ubuntu, you could say something like

sudo apt-get install gcc automake autotools libmagick++-dev \
  libgtk2.0-dev libxft-dev libgnutls-dev libdbus-1-dev libgif-dev

On Fedora you’d say

sudo dnf install -y git make
sudo dnf builddep -y emacs

If you have instructions for other OS-es, or these instructions here are wrong, please leave a comment.

If you need more information on the git flow for Emacs developers, have a peek here.

41 thoughts on “Welcome, New Emacs Developers”

  1. Nice write up, I didn’t know about debbugs.

    Would be good to know how to do this with branches and pull requests! Diffs feel old.

  2. On Windows with MSYS2 (http://msys2.github.io/) :

    If you are on 32 bit:

    export $P=mingw-w64-i686

    if you are on a 64 bit:

    export $P=mingw-w64-x86_64

    then

    pacman -S –needed \
    tar pkg-config automake make autoconf texinfo \
    $P-gcc $P-libpng $P-libjpeg-turbo $P-libtiff \
    $P-giflib $P-xpm-nox $P-gnutls $P-libxml2 $P-librsvg

  3. Is it enough to do just “make” after updating local Emacs repo? When one should use “make clean” or something similar?

      1. A more complete approach is to run ./autogen.sh && ./configure before running make.

        So a total rebuild from a git working copy is:

        git clean -f -d -x -q && git pull && ./autogen.sh && ./configure && make && make install && echo “Emacs build successful” || echo “Failed to build Emacs”

      2. I’d better add a WARNING to make it clear that “git clean -f -d -x -q” *silently deletes all untracked files and directories*. If you have any untracked work-in-progress, or similar, that’s liable to ruin your day.
        The purpose is to reset the working copy to a pristine state, as if it were freshly cloned. If that’s not what you want, please don’t run that command.

      3. Thanks for rapid answer! 🙂
        My question was regarding compilation after further updates. “git clean…” cleans working copy, but then I have to recompile whole Emacs, which takes some time. Is there a faster something like incremental recompilation or just a way to not have to recompile whole thing again?
        BTW another helpful thing for new emacs devs would be how to write and execute unit tests for emacs. I know how to run ERT tests from command line, but how do you test C source (AFAIK it’s possible, there’s a book “Test Driven Development for Embedded C”)?
        Thanks!

        1. You should never have to say “git clean” or anything else in particular. “git pull” and then “make” will rebuild the pertinent parts.
          The only exception is if a major, major change has taken place, and then you may have to say “make bootstrap”, which will rebuild everything, and that takes a while.

    1. No. You should learn LisP for the profound enlightenment experience you will have when you finally get it. :p

      1. Anyone in doubt should simply look at the usage, and construction of the lisp Loop macro.

        Then take a little time to realise what can be done with via. lisp macros.

        Language feature you like? Ok, lisp can do it, or you can implement it.

        For some reason (cost most likely) Lisp missed the boat, or we collectively missed the lisp boat.

        Either way, it’s never too late, Lisp will consume the industry when enough people get it. If not, we’re a stupider species than I previously imagined.

  4. @Oscar

    You can simplify that using bash {,} syntax:

    pacman -S –needed \
    tar pkg-config automake make autoconf texinfo \
    $P-{gcc,libpng,libjpeg-turbo,libtiff,gifli,xpm-nox,gnutls,libxml2,librsvg}

  5. If you want to build on OSX, the default invokation of make will get you an X11 executable. You need to invoke ./configure –with-ns to get a different Makefile. There’s more information in nextstep/INSTALL.

  6. Debian Wheezy (7.8) still provided emacs23 so the sudo apt-get build-dep with emacs23 didn’t really install all the required files. The only thing I needed to change was autotools to autotools-dev. So the full cmd would be:

    sudo apt-get install gcc automake autotools-dev libmagick++-dev \
    libgtk2.0-dev libxft-dev libgnutls-dev libdbus-1-dev libgif-dev

    Thanks for the post! 🙂

  7. As far as I can tell ChangeLog files aren’t being kept up to date on a continual basis anymore. Someone updates them just before a release. So you probably don’t need to worry about merging them anymore.

  8. I think though, one of the hardest part in Emacs contributing worth mentioning is “how do I get emacs to list all changed functions”.

    A month ago while writing a patch I was trying to figure it out on my own, and spent an hour searching and asking on IRC, to no avail. I think `C-x 4 a` should do it, but for me it only pastes a line with the current filename (rather, than all files I changed with all functions in those files). I’m sure there was some way, but I couldn’t find it anymore ¯\_(ツ)_/¯

Leave a Reply