0ec4d6ee43
Making the compile check happen earlier fixes an edge case where the resulting files from a literate config being tangled into multiple files aren't recognized by Doom's package management or autoload generation systems. Disabling byte-compiling fixes an all too common issue where packages and macros are undefined at compile time, causing a plethora of invalid function errors. Leave byte-compilation to `bin/doom compile`!
40 lines
1.4 KiB
EmacsLisp
40 lines
1.4 KiB
EmacsLisp
;;; config/literate/init.el -*- lexical-binding: t; -*-
|
|
|
|
;;; config/literate/config.el -*- lexical-binding: t; -*-
|
|
|
|
(defvar +literate-config-file
|
|
(expand-file-name "config.org" doom-private-dir)
|
|
"The file path of your literate config file.")
|
|
|
|
(defvar +literate-config-dest-file
|
|
(expand-file-name "config.el" doom-private-dir)
|
|
"The file path that `+literate-config-file' will be tangled to, then
|
|
byte-compiled from.")
|
|
|
|
|
|
;;
|
|
(defun +literate-compile (&optional load)
|
|
"Tangles & compiles `+literate-config-file' if it has changed. If LOAD is
|
|
non-nil, load it too!"
|
|
(let ((org +literate-config-file)
|
|
(el +literate-config-dest-file))
|
|
(when (file-newer-than-file-p org el)
|
|
(message "Compiling your literate config...")
|
|
|
|
;; We tangle in a separate, blank process because loading it here would
|
|
;; load all of :lang org (very expensive!). We only need ob-tangle.
|
|
(or (zerop (call-process
|
|
"emacs" nil nil nil
|
|
"-q" "--batch" "-l" "ob-tangle" "--eval"
|
|
(format "(org-babel-tangle-file \"%s\" \"%s\" \"emacs-lisp\")"
|
|
org el)))
|
|
(warn "There was a problem tangling your literate config!"))
|
|
|
|
(message "Done!"))))
|
|
|
|
;; Let 'er rip!
|
|
(+literate-compile)
|
|
|
|
;; No need to load the resulting file. Doom will do this for us after all
|
|
;; modules have finished loading.
|