If built with gccEmacs, in `straight--native-compile-package` step tries
to access $HOME because `comp-eln-load-path` contains
"~/.emacs.d/eln-cache/". It errors on this as it is set to a readonly canary value of
`/homeless-shellter` in the nix build sandbox.
The workaround is twofold:
* Ignore `kill-emacs` from optimization. It would result in eln file
being written before doom sets up the load path outside of HOME.
* The above solution doesn't help in the actual build phase because the
worker processes compiling packages does not inherit this value but
it is set in them at a later time. This causes the build to fail
before `comp-eln-load-path` would be successfully overridden. Having
a writable $HOME does not seem to produce any build output there
hence the override and the check in `postInstall` to verify that the
directory is indeed empty.
The runtime value of `comp-eln-load-path` also had to be changed because
it is by default is located under the volatile `doom-cache-dir` which is
not a part of the derivation so the build time generated `.eln` files
couldn't be loaded from that.
References: #57
New behavior is introduced here:
> commit e632871a115528a9c1ce90d7d2147873009716eb
> Author: Henrik Lissner <henrik@lissner.net>
> Date: Mon Aug 24 00:36:52 2020 -0400
>
> core-cli: backport more refactors from rewrite
>
> Still a long way to go, but this introduces a few niceties for
> debugging CLI failures:
>
> + The (extended) output of the last bin/doom command is now logged to
> ~/.emacs.d/.local/doom.log
> + If an error occurs, short backtraces are displayed whether or not you
> have debug mode on. The full backtrace is written to
> ~/.emacs.d/.local/doom.error.log.
> + bin/doom now aborts with a warning if:
> - The script itself or its parent directory is a symlink. It's fine if
> ~/.emacs.d is symlinked though.
> - Running bin/doom as root when your DOOMDIR isn't in /root/.
> - If you're sporting Emacs 26.1 (now handled in the elisp side rather
> than the /bin/sh shebang preamble).
> + If a 'doom sync' was aborted prematurely, you'll be warned that Doom
> was left in an inconsistent state and that you must run `doom sync`
> again.
>
> May address #3746
The above commit introduces an explicit call to `(kill-emacs)` at the
end of doom cli's main function. This conflicts with `nix-straight.el`'s
package collection as it would run after doom is initialized.
The commit disables `(kill-emacs)` method while package collection is in
progress.
having gnupg around the build triggers emacs to use it for package signature
verification. this would not work anyway because the build sandbox does not
have a properly configured user home and environment.
Fixes: #33
`nix-straight.el` used to require `straight.el` on its own before `doom`
itself was loaded. This had an unfortunate side-effect that
`straight-fix-org` was set to nil after it has been loaded so
`org-version` and `org-git-version` functions were already overloaded.
This was no problem for `org-mode` itself as it has its own overload of
the above mentioned functions, but other libraries such as `elfeed` may
also use these which causes problems.
`nix-straight.el` is updated to a version where it does not preload
`straight` and an advice is provided to `doom` so it loads our version
of `straight` when it supposed to.
References: https://github.com/vlaci/nix-doom-emacs/issues/5
workaround breakage introduced in
commit 6f7bdc801a0b4d1a50f25b3c6d7d74858789a540
Author: Henrik Lissner <henrik@lissner.net>
Date: Mon Dec 16 16:49:34 2019 -0500
Make print! et co always respect standard-output
Newer doom versions (after 873fc5c0db4876d9e1f347fa6cbd2a3a1933df69) has
a rewritten cli interface. I could not figure out how to pass `--no-env`
and `--no-fonts` (should check later if it is a bug in doom)
