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.
The file-size check is obviously not a very reliable way to determine if
the local and remote files are different. Hence we now default to always
uploading all given asset files, replacing any existing ones with the
same file name.
The size check logic is still available via the --asset-size-check flag.
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.
