Hi,
Thank you for your insights.
On Sun, 27 Sep 2020 at 15:12, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> > --8<---------------cut here---------------start------------->8---
> > guix build -m manifest.scm --with-input=emacs-minimal=emacs-next \
> > --with-input=emacs=emacs-next
> > --8<---------------cut here---------------end--------------->8---
>
> Possibly. And then Magit uses emacs-no-x as an input, so we may need to
> also add --with-input=emacs-no-x=emacs-next to the command.
[...]
> Or maybe `package-with-emacs-next' could be more high-level, and handle
> all of these cases. I don't know.
I am not familiar with the Emacs build system. Do the packages need
different flavors of the Emacs VM to be byte-compiled?
For example, the package emacs-magit drags emacs-no-x because of
emacs-libgit, why is emacs-minimal not enough here?
Well, the emacs-build-system depends (implicitly) on emacs-minimal,
only. And the initial patch `package-with-emacs-next' was changing
this, only. However, the package emacs-libgit is cmake-build-system
and the package emacs-no-x is an explicit dependency; which is another
story. :-)
Therefore, the `package-with-emacs-next' could replace the Emacs used
by the build system (emacs-minimal -> emacs-next-minimal) and also
traverse all the graph of dependencies and replace all the Emacs
variants (emacs-{minimal,xwidgets,no-x,no-x-toolkit,wide-int}) in
gnu/packages/emacs.scm by the package emacs-next. I am not sure it
will work. Maybe the Emacs variants should also be rebuilt inheriting
from emacs-next instead of emacs. WDYT?
Does it make sense?
All the best,
simon
