Add support for naming release and builds accordingly when given a git
ref for a pretest (90 or above patch number) or release
candidate ("-rcX" at the end of the tag).
This finally makes Emacs.app with native-comp fully self-contained, no
longer requiring the GCC Homebrew formula to be installed when
loading *.eln files that link against
/usr/local/lib/gcc/11/libgcc_s.1.dylib.
By adding the signing entitlement
com.apple.security.cs.allow-dyld-environment-variables, which allows
dynamic library loading to be controlled via DYLD_* environment
variables. It seems the lack of this was preventing Emacs from loading
the bundled libgcc_s.1.dylib file from Contents/Frameworks.
Fixes#53
This allows much shorter shared library link paths within *.eln files
compared to when using @executable_path, which leaves enough space in
them to sign all *.eln files, while directly having them linked against
the embedded copy of GCC shared libraries.
It seems like Ruby's FileUtils.cp_r method especially was messing with
some file attributes, causing Emacs to print details about loading
various elisp files on startup. While when Emacs.app is copied into the
output build directory using "cp -a" instead of FileUtils.cp_r it does
not exhibit this behavior.
It seems homebrew bottle of GCC for macOS Monterey (12.0) have changed their
directory structure slightly, which caused an issue were we were trying
to rename a specific directory to the same name it already had.
This behavior is still required as it looks like GCC on macOS
Catalina (10.15), the GCC homebrew bottle still uses the old directory
structure.
Relinking is currently failing for some of the *.eln files. See #60 for
details of the error.
Long-term plan is to investigate native-comp's compilation options to
hopefully resolve this issue.
Instead of patching emacs sources before building Emacs, we can use
site-start.el instead for a much cleaner way of setting LIBRARY_PATH
before the user config is loaded.
Previously we just copies the whole "src" directory from the workdir, it
turns out it has some binary files after a successful build, which
caused Apple's notarization process to fail.
As we actually only care about the *.c and *.h files from the "src"
directory, let's explicitly only copy those files.
Annoyingly, when downloading raw files from GitHub, symlinks do not
return the content of the symlink target, but instead it simply returns
the symlink target path (../emacs-28/fix-window-role.patch).
Hence we have to check the patch file content, and if it contains only a
single line of text, we assume it's a symlink, and resolve it relative
to the original download URL.
