Improve native-comp-env-setup patch

[jimeh]

The native-comp-env-setup patch has always been a rather horrible first draft hack. There's a number of fragile areas which can be improved, and also finding a better way to ensure it runs before any native compilation starts would be great. The current advice-add/advice-remove solution for it is horrible.

Additionally it seems like it might be at least partially responsible for Emacs bug #45701.

Improvements:

• [x] Let the build script explicitly write out the GCC directory paths into the patch, as the build script already knows what they are. This will leave the elisp patch only responsible for dynamically looking up the invocation-directory and concatenating it with the explicit paths. This will yield much less logic in the elisp patch itself, and hence much less chance of it breaking anything. (#30)
• [ ] Figure out a better way to run the env setup before any native compilation starts.

[schellj]

I mentioned this in the #45701 thread, but copying here for posterity:

I seem to have found cause of my issue. Since I had been doing builds from several different branches and commits, I had been naming the base-dir of the Emacs.app in concert with the name of the build tarball that build-emacs-for-macos produces to keep track of which was which. E.g., Emacs.app-[feature-native-comp][2021-02-03][1f626e9][macOS-10.15][x86_64].app. If I rename that to just 'Emacs.app', I can no longer reproduce the M-x report-emacs-bug "Wrong type argument: stringp, nil" error that I was experiencing. Thus, somewhere the native-compile-setup-environment-variables patch code doesn't seem to handle that sort of invocation-dir path (presumably due to the special characters).

[jimeh]

@schellj Thanks for finding the root cause, and yes, that makes sense as the patch effectively uses a glob pattern. I'll be getting rid of all the glob behavior, and injecting the exact relative paths from the build script, so the patch will only concat them with the invocation direction. That should make it a lot more reliable :)

[jimeh]

@schellj PR #30 should fix your issue, it's merged in to master and tagged as 0.4.6. I have native-comp working a app bundle called Emacs.app-[feature-native-comp][2021-02-14][3141649][macOS-11.2][x86_64].app. Below is the LIBRARY_PATH value from the process-environment variable:

"LIBRARY_PATH=/Users/jimeh/Projects/build-emacs-for-macos/builds/Emacs.app-[feature-native-comp][2021-02-14][3141649][macOS-11.2][x86_64].app/Contents/MacOS/lib/gcc/10:/Users/jimeh/Projects/build-emacs-for-macos/builds/Emacs.app-[feature-native-comp][2021-02-14][3141649][macOS-11.2][x86_64].app/Contents/MacOS/lib/gcc/10/gcc/x86_64-apple-darwin20/10.2.0:/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"

[schellj]

Thanks. I'll attempt a build tomorrow and let you know if it doesn't work as expected.

[jimeh]

This issue was resolved with #59.