bug#41732: New ’package-with-emacs-next’ procedure

[zimoun]

Hi,

Thank you for your insights.

On Sun, 27 Sep 2020 at 15:12, Nicolas Goaziou <mail@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