I build three different release flavors of Emacs:
These are bleeding edge builds and may have bugs. They are built directly from the public Git repository. I try to build these nightly.
The scripts I run basically just configure and build right from the GNU source—I don't add any patches or any extraneous lisp packages. I do include the old Carbon icon on the disk image because I like it better than the new Cocoa icon but it is not enabled by default.
Emacs is built on various versions of Mac OS X: 10.12 and 10.14 as of 2024-07-04 (64 bit only). All the binaries are combined into a single executable and a small Rust launcher chooses which binary to run based on the machine's OS and architecture.
Why not just use a fat binary? Because fat binaries can only hold 1 of each architecture and Emacs has multiple x86_64 architectures binaries.
Why are there multiple x86_64 binaries? Even though recent versions of Emacs contain runtime feature detection, there is an issue with some library dependencies.
Because of the unstable nature of nightly builds, and (sadly) the relative fragility of OS X running on VMs, there may be days missing here and there.
The current Nightlies and releases will not run on these versions of MacOS. The last built release and nightly that do work are listed.
| MacOS Version | Last Working Release | Last Working Nightly |
|---|---|---|
| 10.4 (PowerPC) | Emacs-24.5-1 | Emacs-2014-10-12 |
| 10.6 - 10.8 (Intel) | Emacs-26.1-2 | Emacs-2018-06-13 |
| 10.9 | Emacs-26.3 | Emacs-2019-12-03 |
| 10.10 | Emacs-27.1-1 | Emacs-2020-12-29 |
| 10.11 | Emacs-29.3-1 | Emacs-2024-06-24 |
Emacs builds as of 2024-07-04 no longer support macOS 10.11 (El Capitan). This is because the Jenkins Build Executors now require a version of Java (JDK 17) that doesn't work on macOS 10.11.
Emacs builds as of 2023-08-17 now include SQLite support, including release 29.1-1.
Emacs builds as of 2023-03-09 now include librsvg and
tree-sitter*. Yay! This is accomplished by building with Nix instead of
compiling everything with a custom script. This makes getting
the dependencies installed a breeze. If you install Nix on your mac, grab the
dependencies.nix file from the emacs-build repository
and run:
$ nix-shell dependencies.nix
then it will drop you into a new shell with all the same dependencies ready to go. This is so easy it might pave the way for Native Compilation…
* Requires 10.14 and higher to use. The builds will still work with macOS releases as old as 10.11, but those older OSes won't get those features. Nix only supports macOS 12 and up. It might be time to either add a 10.12 build into the mix or to just drop support for 10.11. Honestly 10.11 is kind of precarious right now—when I was investigating whether Nix would install on something that old I found that the TLS (in curl at least) was so old that nothing would download. If the dependency build cache ever gets wiped it'll be extrememly time consuming and painful to get it to where it is right now.
Emacs builds as of 2022-04-24 are notarized (finally). The nightly from 2022-04-24 is the first notarized nightly. This also enables macOS's "hardened runtime", which appears to not break anything but I'll let it simmer for a week or so before rebuilding a notarized release.
Emacs builds as of 2022-04-04 use a binary launcher instead of a Ruby script. The nightly from 2022-04-04 is the first nightly build with the binary launcher (written in Rust). Emacs 28.1-1 is the first release with the binary launcher.
The Rust launcher should be better for 2 reasons:
Starting with macOS 11 (or 10.15?), Apple warns the user when an app tries to
access certain places on the filesystem
(~/Documents, ~/Library, etc). With the Ruby
launcher, the only way to allow this is by
allowing /usr/bin/ruby, which is unintuitive and also allows more
access than maybe you'd want. Having a native binary should make this process
more clear and give permissions to only the intended app.
Apple has been threatening to remove the /usr/bin/ruby (and Perl
and Python) binaries. That would mean we'd either have to bundle Ruby with
Emacs (yuck), write the launcher in shell (double yuck!), or make it a native
binary.
There is another option: Remove the launcher entirely. Some day I hope to get around to doing this. But it requires a lot of testing. Emacs can be compiled against older Cocoa APIs but I think there are a few extra system supplied libs (libxml2, for instance) that it links against. Those can change across OS releases so to make it work everywhere we'd probably want to bundle them (with the downside that they don't get security patches).
The binary launcher also has a new feature: If it
detects that it was launched from launch service (by double clicking in Finder,
or via the dock, or through the cli open command) then it will
launch a login shell and copy the env vars into its own process. This is because
it has become extremely difficult for a user to inject env vars in recent macOS
versions. There are all sorts of workarounds, but this seemed like a easy way to
make most people's development environments "just work". There is more
discussion of this feature
here.
Emacs builds as of 2021-03-26 include arm64 support (native Apple Silicon binaries). This includes the 27.2-1 release.
Also starting now, gnutls, jansson, libffi and their dependencies are not built with Homebrew—it kept breaking old builds, and moving the "unsupported" bar forward much quickly than I wanted to. Now I have tighter control over the dependency build process at the expense of having to maintain a bunch of custom code to download, configure and make them.
I also bumped up the minimum OS version to 10.11 because building the dependencies on such an old OS was too hard.
Emacs builds from 2020-03-03 to 2020-05-12 do not include support for 10.9-10.13. Homebrew stopped being able to compile gnutls and doesn't accept bug reports for 10.9 and so I dropped it. It didn't occur to me at the time that dropping 10.9 and not replacing it with something else would also kill 10.10, 10.11, 10.12, and 10.13. So those nightlies and the 27.0.90 pretest were only built for 10.14 and above.
Today I added 10.10 into the build so nightlies from 2020-05-13 and the 27.0.91-1 pretest should work with anything from 10.10 to 10.15.
Emacs builds as of 2018-12-05 do not include support for 10.6-10.8. Only 10.9 and above are being supported. The SSL issue I noted back in 2018-04-10 is deeper now—I cannot download the Ruby that I need to run the build scripts on those old OSes. I had to wipe the Jenkins workspace and it basically killed those builds. At the same time I ran into an Emacs bug that was causing the elisp to not compile on 10.6. And yet another bug was causing all the build slaves to be offline. I procrastinated figuring these 2 issues out for 6 months and finally decided to just remove support for these old OSes. The last Emacs builds to support 10.8, 10.7 and 10.6 are Emacs 26.1 and the Emacs nightly from 2018-06-13.
Recent Emacs builds (since 2018-04-10) do not include gnutls on 10.8 and lower. Unfortunately the method of downloading gnutls (Homebrew) stopped working because the servers stopped supporting old SSL versions and 10.8's SSL libs aren't new enough. The Emacs 26.0.91-1 pretest is the last version that has gnutls on Mac OS 10.8.
Recent Emacs builds (since 2016-08-15) include gnutls (except on Mac OS 10.6—Homebrew doesn't work on 10.6 and I don't want to spend a lot of time compiling gnutls on a platform that is barely used). You can now use https urls in the package configuration. Yay!
Recent Emacs builds (since 2012-12-16) have been built against Mac OS 10.7 (Lion) and have Lion full screen support if you are running on Lion or Mountain Lion. They also have better retina display support and are code signed. Also Yay!
Recent Emacs builds (since 2009-12-09) have 64 bit Intel support in the Universal Binary. Yay!
I rewrote the build scripts in 2014 to make them more modular so I could easily control them with Jenkins. I also moved them from shell to Ruby, which cleaned things up tremendously. They still aren't documented super well, but they should be easier to read, at least.
— David Caldwell