The Frameworks folder is the recommended location to store shared
libraries within macOS application bundles. Previously we stored them in
Contents/MacOS/lib.
Latest nightly builds already store all *.eln files under the Frameworks
folder, so it seemed like a good time to make the change with the
library bundler/embedder too.
The ref was not correctly set when loading a build plan, resulting in
the set of patches being selected were always for Emacs 28.x, preventing
builds of Emacs 27.x and 26.x.
In my initial testing without full native-comp AoT, Emacs seemed to
somehow launch fine. But with a AoT build it complains that it can't
find *.eln files in the original paths that contained dots. But since we
have to customize those folder names removing the dots to make Apple's
codesign happy, we also need to update Emacs.pdmp too.
This will be used by the jimeh/homebrew-emacs-builds brew tap repository
in combination with brew livecheck to automatically update cask formulas
to the latest nightly builds from the jimeh/emacs-builds repository.
Apple's codesign CLI tool will throw an error when signing application
bundles, if any folder within the app's Contents/MacOS folder contains
two dots.
The recent relocation of the native-lisp folder from
Contents/Resources/native-lisp to
Contents/MacOS/lib/emacs/28.0.50/native-lisp is causing code signing to
fail.
The workaround here simply replaces dots (.) with hyphens (-), causing
the following folder renames:
Contents/MacOS/lib/emacs/28.0.50/native-lisp/28.0.50-852ecda2 --> Contents/MacOS/lib/emacs/28.0.50/native-lisp/28-0-50-852ecda2
Contents/MacOS/lib/emacs/28.0.50 --> Contents/MacOS/lib/emacs/28-0-50
To ensure Emacs can still find the bundled native-lisp files, we use a
symlink:
Contents/native-lisp -> MacOS/lib/emacs/28-0-50/native-lisp
This type of fix is not ideal, but its the only way I know of getting
around this issue right now.
And we're already doing a similar thing for the embedded gcc libraries.
Latest commits to master as of June 26, 2021 have moved *.eln files back
to: MacOS/lib/emacs/**/native-lisp
Even though the symlinks are most likely no longer needed, I don't know
of an easy way to determine if they're required or not, so for now,
they'll be created to ensure older native-comp branch SHAs can still be
built.
The sign command signs Emacs.app application bundles with Apple's
codesign utility.
It does a few things outside of just executing codesign:
- Is aware of *.eln native-compilation files, which need to be
explicitly searched for on disk and passed to codesign, as they are
not detected when using the "--deep" option.
- Is aware of Contents/MacOS/bin/emacs CLI helper tool which we add into
the application bundle, and specifically passed it to codesign as
well.
- By default provides a set of entitlements which are relevant for Emacs
when running codesign.
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.
The API tarball endpoint is subject to API rate limits, while the
non-API tarball endpoint is not. This should reduce the risk of rate
limit errors for people who don't have a GITHUB_TOKEN environment
variable set.
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.
It turns out all *.eln files link against the libgcc dylib in homebrew:
/usr/local/lib/gcc/11/libgcc_s.1.dylib
So here we find all *.eln files in all relevant paths they may be
depending on how old of a native-comp source tree we're building, and
copy in any shared libs that resides within the homebrew prefix. Just
like we do for all other binaries that we copy libs for.
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
