Relinking the /usr/local/lib/gcc/10/libgcc_s.1.dylib shared library
within bundled *.eln files is still causing issues with code signing, so
I'm adding an option to toggle *.eln file re-linking on/off, with it on
by default.
When shared libs are stored in `Contents/Frameworks`, the re-link path
for `/usr/local/lib/gcc/11/libgcc_s.1.dylib` within bundled *.eln files
becomes `@executable_path/../Frameworks/libgcc_s.1.dylib`, which seems to
not leave enough space in the *.eln binary header to add a code
signature with codesign.
This used to work when shared libraries were bundled into
`Contents/MacOS/lib`, leading to a shorter relink path of
`@executable_path/lib/libgcc_s.1.dylib`, which does leave enough space
to add a code signature to *.eln files.
With the recent move of shared libraries and native lisp *.eln files to
Contents/Frameworks, the re-linking paths became longer, causing code
signing to fail with headerpad errors. This change ensures there's
enough space within binary files for longer shared library relink paths,
and code signing payloads.
The --test-release-type flag was essentially broken and ignored, always
creating a prerelease release for test builds. Now it can also produce
draft releases.
Stable builds are based off of release git tags in Emacs' git
repo. Examples of what release tags look like:
- emacs-26.1
- emacs-26.2
- emacs-26.3
- emacs-27.1
- emacs-27.2
When the specified git ref looks like a stable release, the plan command
will generate a release a different and simpler release name that does
not include the date, git sha or ref. Instead, for "emacs-27.2" for
example, the emacs-builds release name will be "Emacs-27.2".
The "build name", used for naming the disk image, still retains the same
format as the nightly builds.
Also, non-stable releases are now marked as pre-release on GitHub by
default.
The reason for the different release name format for stable builds is
both to separate them, but also to make it easier to keep the version of
the homebrew cask as simply "27.2".
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.
