Allow ahead-of-time native-compilation during CLI operations that
install or update packages. This will not retroactively native-compile
already-installed packages, you'll need to use --rebuild to do so.
(This is a stop-gap solution until the v3.0 release)
Fix: #6811
It seems the temporary branch that 'doom upgrade' creates is sometimes
left over after a 'doom upgrade', preventing the next 'git fetch' from
completing.
Ref: #7771
Prior to this, -B would suppress the prompt for package rebuilding if
your Emacs version or hostname changed. Now, it fully inhibits
rebuilding in either case.
Fix: #7760
Ref: cff091982e
This changes 'doom sync' to be smarter about responding to changed
package recipes/pins, changes in Emacs version, or instances where the user
has copied a config to a new system.
In all these cases, the user would formerly have to know about a
specific combination of 'doom sync -u' and 'doom build' to ensure Doom
is in a good state. With this change, 'doom sync' handles all these
cases.
Also, 'doom build' is now deprecated (and 'doom sync' now has a
--rebuild option to mimic its old behavior).
Also also, sometimes, a package may silently fail when cloned (which
used to result in an empty repo). Now, if this is detected, cloning will
be re-attempted up to 3 times before aborting with much more visible
error.
Note: these are stopgap solutions, until v3 is finished.
BREAKING CHANGE: This removes the 'doom compile' and 'doom clean'
commands, and offers no immediate replacement for them (and no plan to
include one). In the future, byte-compilation of Doom's internals will
be baked into 'doom sync', but until then, Doom is not optimized to take
advantage of byte-compilation, and forcing it provides no benefit.
- Adds doom-module-packages-file and doom-module-metadata-file.
- Uses them and the other doom-module-*-file variables where they were
previously hardcoded.
- Add .el extension to doom-module-{init,config}-file; it is now the
consumer's responsibility to strip/change/keep the extension as they
see fit.
In the future, should doom-core-dir or {doom-core-dir}/packages.el
change, 'doom upgrade' won't leave the repo in a broken state.
Unfortunately, this cannot retroactively prevent the issue; users will
experience this as soon as they update to b9933e6 or beyond, so users
will have to upgrade manually to overcome it:
cd ~/.emacs.d
git reset --hard 35a89bdfa6
git pull origin master
doom sync -u
Fix: #6598
Amend: b9933e6637
BREAKING CHANGE: This restructures the project in preparation for Doom
to be split into two repos. Users that have reconfigured Doom's CLI
stand a good chance of seeing breakage, especially if they've referred
to any core-* feature, e.g.
(after! core-cli-ci ...)
To fix it, simply s/core-/doom-/, i.e.
(after! doom-cli-ci ...)
What this commit specifically changes is:
- Renames all core features from core-* to doom-*
- Moves core/core-* -> lisp/doom-*
- Moves core/autoloads/* -> lisp/lib/*
- Moves core/templates -> templates/
Ref: #4273
