Since 87a024e, the profile init files are no longer byte-compiled, so
this block of code -- responsible for deleting byte-compiled init files
-- is no longer needed.
Amend: 87a024ee90
The performance benefit of doing so has always been questionable or, at
best, negligible, but has caused numerous issues over the years. The
latest one being #8162, where byte-compiling a profile init file with
too many package autoloads would consume more than 255 opcodes, causing
an overflow error.
For simplicity's sake, Doom will no longer byte-compile this file.
Fix: #8162
This is an old issue that's haunted Doom for a while. I had initially
planned to wait until the switch to Elpaca, but I decided to just sit
down and solve this.
This ensures package autoloads are always written in depth-first
dependency order to Doom's profile init file, preventing load-order
issues like the notorious void-function geiser-activate-implementation
error. `geiser` needs to be built before any `geiser-*` plugins, since
its plugins reference variables/functions in geiser's own autoloads, but
there's no way to enforce package order in `straight--build-cache`
currently, and subsequent package updates (or just deleting package
directories by hand) can change the order of straight's build-cache in
subtle ways.
Fix: #7693Fix: #7472
The issue required a more systemic fix, because the former (before
9e6c46a even) only recorded `Info-directory-list` for the packages that
were installed/updated in that `doom sync` session, forgetting all
packages installed in the past.
Fix: #8143
Amend: 9e6c46a332
Some packages do funky things in their autoloads, so care is needed to
closely emulate an autoloading environment when loading them, however,
in 8cafbe4, Doom wraps these autoloads in a function, thus ensuring
they're executed without `load-file-name` or `load-in-progress` set,
which some packages will expect these in their autoloads.
This fixes the (wrong-type-argument stringp nil) error some folks see
with certain packages doing said funky things in their autoloads (like
realgun in the :tools debugger module).
Fix: #8143
Amend: 8cafbe4408
BREAKING CHANGE: This restructures Doom's core in an effort to slim it
down and partially mirror architectural changes coming in v3. This is
part 2 of 3 commits (part 1 being 1590434), done to facilitate a change
in part 3 that will introduce a new `doom!` syntax for pulling
third-party module libraries from remote sources (similar to `package!`
statements). I am backporting this from V3 so I can move our modules out
into separate repos sooner than later, so development on modules can
continue separately without interfering with v3's roll out.
Though this is labeled a breaking change, it shouldn't affect most users
except those few tinkering directly with Doom's internals.
Ref: 15904349cf
