Detect module flags by walking package.el files.
This still does not build all dependencies, because some are enabled
only if some flag or other module is disabled. But this should be close.
...not yet with all flags, but that's the next step.
This surfaced several problems not caught by the existing "full" build,
because that did not enable dependencies conditionally enabled if a
second module is enabled.
There are a small number of dependencies only enabled if a second module
is *not* enabled, which I intend to add some manual tests for.
Both approaches are about equivalent, but since I'm trying to make the
profile loader optional and there's no way I can make the wrapper
optional, let's move this around...
Instead of passing the path down from the profile loader to init.el,
just substitute the path into init.el.
This requires moving DOOMDIR generation into the same derivation as
profile build to avoid a circular dependency.
This unsets DOOMPROFILE from inside the profile loader, which should
result in Doom behaving as if we were not using profiles at all.
I'm marking this experimental in part because it feels like a hack, and
in part because this is not sufficient to fix `doom doctor`.
Buliding an empty autoloads file is harmless. Removing it would only
have been useful if I was able to skip straight.el initialization
entirely: now that I'm storing its build cache it no longer helps.
Add an (empty) straight.el build cache to the generated profile, and
load it when Doom calls `doom-initialize-core-packages` (which normally
does so by side effect).
Unfortunately requires adding to pre-init: Doom overrides
`straight-base-dir`, and we need to override that override.
Partially fixes package help.
I somehow managed to lowercase build-profile and build-profile-loader
when I split them out of cli2.el. Undo this.
The only load-bearing capitalization was DOOMDIR in the profile loader.
Everything else was comments and docstrings.
Our cli.el ended up in the profile used at runtime. Although we could
have fixed overwriting a user's cli.el by appending to it, that still
would have leaked our build commands into the build.
This approach should be equivalent and reduces our profile modifications
to replacing packages.el (which is kind of the point) and prepending to
init.el (unfortunate, but seemingly necessary).
Removes the need to build a stage1 DOOMDIR, we can just use the user's
DOOMDIR directly.
The same approach should work for the next stage, removing the need to
leave our cli.el in the final DOOMDIR.