Liliana Marie Prikler <liliana.prik...@gmail.com> writes: > with the grafting of Emacs 29.3 to 29.4, we see that Emacs itself is > still correctly loaded, but Emacs libraries (e.g. dash) aren't. > > (comp-el-to-eln-filename (expand-file-name "…/dash.el")) > => $HOME/.config/emacs/eln-cache/29.4-46e5bcbe/dash-2.19.1/dash.eln > > find $(guix build emacs-dash --with-input=…) -name 'dash.eln' > => $PREFIX/lib/emacs/native-site-lisp/29.3-62809b9a/dash.eln > > It seems that we might have to rebuild emacs native-compiled packages > even if emacs itself is grafted.
I had missed this message, previously. IIUC, the issue is that replacement packages are grafted post-build. This means that when emacs-dash is built, its AOT native-compilation happens with Emacs 29.3. However, at run-time Emacs 29.4 gets grafted in. There are at least two possible ways (ignoring feasibility) to resolve this: 1. When emacs-dash etc. is being built we use Emacs 29.4 for native compilation. 2. When emacs-dash etc. is being built we use Emacs 29.3 for native compilation, but ensure that said files are transferred to a location where Emacs 29.4 is able to find them. Which do we desire? My belief is that 1 is what we need, and that doing 2 may be inadequate for ensuring that appropriate security fixes are deployed (consider the case where the bug is in a macro in Emacs core). If my analysis above is correct, then the question (which I don't know the answer to) is can 1 be accomplished with grafts? -- Suhail
