emenel/doomemacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Revert to straight's original bytecomp behavior

Browse source 
Half-reverts 628f0a9, which forced straight to byte-compile packages in
another Emacs session, which produced failures for packages that didn't
properly load their compile-time dependencies (e.g. macro calls).

But now, I realize that _not_ failing in those cases is worse and
produces odd byte-code issues like #1657 or invalid-function ((date
date)) errors. This doesn't guarantee a fix, but at least takes the ball
out of Doom's court, and gracefully fails to uncompiled packages, rather
than incorrect bytecode.
This commit is contained in:
Henrik Lissner 2021-05-14 15:08:10 -04:00
parent 9e5ba5fd6c
commit fb89327ff2
1 changed files with 0 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

19
core/core-packages.el
View file

@ -111,25 +111,6 @@ uses a straight or package.el command directly).")
(append (apply orig-fn args) ; lockfiles still take priority
(doom-package-pinned-list)))
(defadvice! doom--byte-compile-in-same-session-a (recipe)
"Straight recompiles packages from an Emacs child process. This is sensible,
but many packages don't properly load their macro dependencies, causing errors,
which we can't possibly police, so I revert straight to its old strategy of
compiling in the same session."
:override #'straight--build-compile
(straight--with-plist recipe (package)
;; These two `let' forms try very, very hard to make byte-compilation an
;; invisible process. Lots of packages have byte-compile warnings; I
;; don't need to know about them and neither do straight.el users.
(letf! (;; Prevent Emacs from asking the user to save all their
;; files before compiling.
(#'save-some-buffers #'ignore))
(quiet!
;; Note that there is in fact no `byte-compile-directory' function.
(byte-recompile-directory
(straight--build-dir package)
0 'force)))))
;;
;;; Bootstrappers