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
This 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.
When 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.
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.
The “Git for Emacs Devs” page goes into the gritty details of branching and stuff…
On Debian/Ubuntu you could actually do: sudo apt-get build-dep emacs24
Thanks; I’ve now updated the article with that instead
And on Fedora, with yum-utils installed: yum-builddep emacs
Thanks; I’ll update the recipe.
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
That’s a lot shorter than the instructions here:
http://sourceforge.net/p/emacsbinw64/wiki/Build%20guideline%20for%20MSYS2-MinGW-w64%20system/
Would they produce the same result?
I actually doubt people who said they can’t contribute because of bazaar will now contribute because of git.
I will.
Why?
Is it enough to do just “make” after updating local Emacs repo? When one should use “make clean” or something similar?
From a fresh “git clone” checkout, it’s sufficient to just do a “make”.
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”
There is a GNUmakefile in the checkout. If you’re running GNU make, it will do everything you need.
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.
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!
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.
What about unit testing?
Genius to have such a simple workflow. I predict an outpour of new features, at least one from me!
Great material! Should i learn Lisp to contribute to Emacs? Thanks.
No. You should learn LisP for the profound enlightenment experience you will have when you finally get it. :p
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.
@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}
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.
That sounds like something that should be changed, perhaps? I would assume that the vast majority of Emacs users on OS X wants the native build.
git: is blocked at work. I wish it were hosted on a http:// or https:// address
Update to self: Now
works!
Actually, the link is: http://git.savannah.gnu.org/r/emacs.git
Thanks for this post! I’ve never compiled emacs before, and it was way easier than I expected! Now I can have the bleeding edge 🙂
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! 🙂
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.
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 ¯\_(ツ)_/¯