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
Apple's codesign CLI toolthrows a "bundle format unrecognized" error if
there are any folders within the application that contain two dots in
their name.
Hence we need to get rid of the one instance of that we end up with from
GCC, and update the native-comp patch accordingly.
As of writing, this means renaming:
Emacs.app/Contents/MacOS/lib/gcc/11/gcc/x86_64-apple-darwin20/11.1.0
To:
Emacs.app/Contents/MacOS/lib/gcc/11/gcc/x86_64-apple-darwin20/11
This seems to be the cause of SVG rendering crashing, as it re-links
libiconv.2.dylib from /usr/lib/libiconv.2.dylib to
@executable_path/lib/lib/libiconv.2.dylib within libintl.8.dylib. When
this re-linking does not happen, SVG rendering works without crashing
Emacs.
Some further testing is needed by installing brew dependencies by
building them from source, in an attempt to get various libraries all
linking to homebrew-built versions, to get as many shared libraries as
possible embedded into the application bundle.
Fixes#12
Recent builds places the native-lisp cache folder within
Contents/Resources on macOS, and correctly deals with finding them. This
means the Contents/lisp and Contents/native-lisp symlinks are no longer
needed.
Hence we skip their creation altogether if we find any
Contents/Resources/native-lisp/**/*.eln files.
Also used existing `CFLAGS` and `LDFLAGS` environment variable values,
so a user can easily set these when running the build script to add more
paths. Previously they were set to explicit values ignoring any existing
value.
This might help resolve issues where libgccjit.h is not found as
reported in issue #20. Though I have not been able to reproduce this
myself, it seems adding the libgccjit's include dir has solved the issue
for some.
