This changes the filename pattern of the resulting archive, for example:
Old:
Emacs.app-[master][2021-05-19][6ae3f7e][macOS-11.3][x86_64].tbz
New:
Emacs.2021-05-19.6ae3f7e.master.macOS-11-3.x86_64.tbz
Emacs.app also resides within a folder in the archive now instead of the
in the root. For the above example, the path to Emacs.app within the
archive would be:
Emacs.2021-05-19.6ae3f7e.master.macOS-11-3.x86_64/Emacs.app
Archive creation can also be skipped by passing in --no-archive, which
will instead leave a build folder with the same name as the archive.
If you want to keep the build directory, and also a create archive, pass
in --archive-keep-build-dir.
BREAKING CHANGE: New archive naming convention, and folder structure
within archive.
This makes the -march=native CFLAG optional, and disabled by default,
but still available through a new --native-march flag.
It should make builds more portable between machines, as previously it
was very common to get a CPU architecture error on launch if you moved
the build to a different machine running a different generation of a
Intel CPU.
From what I've understood, when using the -march=native CFLAG clang will
make as many optimizations possible based on the exact set of CPU
instructions available on the specific CPU it's compiling on.
In theory this leads to a more optimized build, though I haven't
personally noticed any difference. But it also leads to less portable
builds, for example builds from a Intel-based 2020 MacBook Pro just
crash with a unsupported CPU architecture error when run on a
Intel-based 2016 MacBook Pro.
This should let people on shared connections use the script if they
have a GitHub Personal Access Token available in the GITHUB_TOKEN
environment variable.
When making unauthenticated API requests to GitHub, requests are rate
limited to 60 requests per hour based on source IP address. Hence on
shared connections the rate limit may easily be exceeded.
When making authenticated API requests to GitHub, up to 5000 requests
per hour is allowed, based on the authenticated user rather than source
IP address.
This makes setting up a "emacs" terminal command that works with the
self-contained Emacs.app bundle much simpler, as you just need to add
Emacs.app/Conents/MacOS/bin to your PATH.
For example, if you place Emacs.app in /Applications, add this to your
shell setup:
if [ -d "/Applications/Emacs.app/Contents/MacOS/bin" ]; then
export PATH="/Applications/Emacs.app/Contents/MacOS/bin:$PATH"
alias emacs="emacs -nw" # Always launch "emacs" in terminal mode.
fi
The launcher script works by figuring out it's own absolute path on
disk, even if you are using a symlink to the script, it will resolve to
correct real path. This allows it to execute the main
Emacs.app/Contents/MacOS/Emacs executable via the correct path, so it
can correctly pick up its dependencies from within the Emacs.app bundle.
Fixes#41
The underlying patching code was removed in v0.4.1 (commit
70bf6b05d5), as it was no longer needed,
but the related CLI flag and README info was mistakenly left in place.
The new libgccjit Homebrew formula negates the need to install a custom
patched gcc formula from source to get libgccjit.
As it's a separate formula, the file structure is a bit different
though, requiring some changes to the script. This means it is no longer
compatible libgccjit from the custom gcc formula. If you already have
the custom patched gcc formula installed, you can replace it with the
standard gcc formula by running:
brew reinstall gcc
In theory though, it should work even with the patched gcc formula, as
long as libgccjit is installed too. But it will probably produce a
Emacs.app that's around 35MB larger than it needs to, thanks to
duplicating the libgccjit.so.0.0.1 file within the final application.
BREAKING CHANGE: Standard Homewbrew `gcc` and `libgccjit` formula are now required for native-comp, instead of the custom patched gcc formula.
Recent builds seem to pre-allocate empty `*.eln.tmp` files rather than
empty `*.eln` files. So the issue of empty `*.eln` files preventing
Emacs from starting should no longer be an issue.
I'm leaving #3 open for now, in case anyone is using older git SHAs from
the list of known good commits in #6.
The feature/native-comp branch no longer supports the use of the
NATIVE_FAST_BOOT environment variable. It has been replaced by
NATIVE_FULL_AOT (Ahead of Time compilation).
As the new environment variable's value is opposite of the old one, it
is disabled by default.
Under the hood, the --[no-]native-full-aot option still sets the
NATIVE_FAST_BOOT environment variable as needed to ensure it works as
expected when producing builds against older commits, and also newer
ones.
BREAKING CHANGE: Deprecate `--[no-]native-fast-boot` option in favor of `--[no-]native-full-aot`
When SVG support is enabled via librsvg, launching builds of Emacs 27.1
or later from the Finder into GUI mode will crash Emacs if the fancy
startup screen is used. This crash has been observed with librsvg
2.46.4, 2.48.7 and 2.48.8.
Hence SVG image support is now disabled by default. Should you need it,
you will need to disable the startup screen to avoid Emacs crashing, by
putting this in your init.el:
(setq inhibit-startup-screen t)
The cause of the issue seems to be the `image-size` function as called
from `use-fancy-splash-screens-p`.
The solution to get libgccjit properly working, and embedded in
Emacs.app included:
- The contents of GCC's lib folder (`/usr/local/opt/gcc/lib`) is copied
into the `Contents/MacOS/lib-<arch>-<os_version>` folder.
- Setting `LIBRARY_PATH` environment variable to correct GCC lib
folders within Emacs.app. This is done through a bash launcher script
which replaces the regular `Contents/MacOS/Emacs` executable. The main
Emacs executable itself is named `Emacs-bin` now instead, so anything
that depends on the exact process name will need updating.
- The launcher script also adds `Content/MacOS/bin` and
`Content/MacOS/libexec` folders to the PATH environment variable, to
so ensure binary tools packaged into Emacs itself are available. This
is done even when not doing a native-comp build. The launcher script
skips setting LIBRARY_PATH if it's not a native-comp build.
This should hopefully resolve both #5 and #7.
The `feature/native-comp-macos-fixes` has seemingly been updated about
once a week with latest changes from `feature/native-comp`.
As the fix in the branch is desired, a custom function that applies the
same kind of fix has been added. This should be more reliable than just
downloading the git diff as a patch.
As detailed in Update 11 (https://akrl.sdf.org/gccemacs.html#org4b11ea1)
the `*.eln` cache location has been changed, which initially broke
builds.
This fixes those issues, and also simplifies usage of the build-script
by:
- Auto-detecting native-comp support if not explicitly enabled/disabled
with CLI flags.
- Auto-detecting number of logical CPU cores on your machine, and
defaulting the `-j` option to said number to ensure fast builds.
- Enable XWidgets by default, only skip if `configure` script doesn't
support it (Emacs 26.x and earlier).
Instead of just installing a pre-patched gcc formula, copy the local
formula from Homebrew and apply a patch to it, before then installing
it. This should be a lot more future-proof.
Notes:
- The sRGB patch is now a simple text-replacement, as diff/patch files
seem to just fail. Even Homebrew's emacs formula does it this way.
- Removed fullscreen patch, as Emacs 24.4 includes fullscreen support on
OS X, both native and pre-Lion style fullscreen. More details here:
http://www.emacswiki.org/emacs/FullScreen#toc23
This also applies some kind of convention for the available options.
`--srgb` is still defined for backwards compatibility, but it technically
does nothing.
