Otherwise, the compilation is affected nondeterministically by the state of the running Emacs. Hasn't bit me yet, but I know it will someday.
Forgive the drive-by comment, but the async package provides this facility natively. Might save you time and trouble to reuse that feature.
Just leaving this here for how the async package @slippycheeze mentioned does it:
https://github.com/jwiegley/emacs-async/blob/master/async-bytecomp.el#L137
Yes async package provide async-byte-recompile-directory that you can use safely instead of
byte-recompile-directory, this will avoid bugs when packages rename macros, variables etc...
We are using this with Helm since long time now, Magit use this too.
Hasn't bit me yet, but I know it will someday.
Looks like "someday" turned out to be a little over three years: https://github.com/raxod502/straight.el/issues/624#issuecomment-731693015
Eh, could have been worse---I'll take it.
Radon Rosborough notifications@github.com writes:
Hasn't bit me yet, but I know it will someday.Looks like "someday" turned out to be a little over three years: #624 (comment)
Eh, could have been worse---I'll take it.
Didn't follow the full thread, but it seems it is about compiling
packages async.
Compiling packages async is needed with package.el which does the
compilation of packages straight after fetching them i.e. while the old
package version is still loaded, it is here the problem happen if e.g. a
macro is modified/renamed in new package, I made
async-bytecomp-package-mode (see
https://github.com/jwiegley/emacs-async/blob/master/async-bytecomp.el#L151)
for this reason.
I am new to straight.el and haven't yet looked at its code carefully,
but it seems the packages are recompiled when emacs restart, so at this
point the old version of package is no more loaded and IMHO there is no
need to compile it async because you can't hit the problem described
above, but maybe it is because I always restart emacs after calling
straight-pull-all? But what about people using straight-rebuild-package
or straight-rebuild-all (not good IMO unless you know what you are doing)?
Thanks for straight.el.
--
Thierry
You are correct in that the specific package.el problem that you describe does not also happen with straight.el, unless you use straight-rebuild-package. However, there are other issues. One is that byte-compiling a package causes it to be loaded. This means that in some inits, a package will be eagerly loaded, while in others, it won't be. This is bad for reproducibility, because sometimes a package being eagerly loaded can either surface or hide a bug. Another issue relates to a complex tangle of Org things, which is described in https://github.com/raxod502/straight.el/issues/624#issuecomment-731693015 as I mentioned earlier.
Most helpful comment
Forgive the drive-by comment, but the
asyncpackage provides this facility natively. Might save you time and trouble to reuse that feature.