Hi Ludovic,
Ludovic Courtès <l...@gnu.org> wrote:
> Mark H Weaver <m...@netris.org> skribis:
>
>> (define-public emacs-next
>> (let ((commit "c36c5a3dedbb2e0349be1b6c3b7567ea7b594f1c")
>> (revision "0")
>> (emacs-version "27.0.91"))
>> (package
>> (inherit emacs)
>> (name "emacs-next")
>> (version (git-version emacs-version revision commit))
>> (source
>> (origin
>> (inherit (package-source emacs))
>> (method git-fetch)
>> (uri (git-reference
>> (url "https://git.savannah.gnu.org/git/emacs.git";)
>> (commit commit)))
>
> This can be handled with ‘--with-git-url’.
I think that wouldn't work in this case, because we also need to
preserve the existing 'patches' and 'snippet' fields, which I arranged
to inherit above via (inherit (package-source emacs)). That probably
deserves a comment, since it's easily overlooked.
>> (sha256
>> (base32 "0mlrg2npy1r79laahkgzhxd1qassfcdz8qk1cpw7mqgf6y5x505h"))
>> (file-name (git-file-name name version))))
>> (native-inputs
>> `(("autoconf" ,autoconf) ; needed when building from trunk
>> ,@(package-native-inputs emacs)))
>
> For this, we’d need a new ‘--with-extra-input’ package transformation
> option or similar. That way, we wouldn’t even need an ‘emacs-next’
> package: people would just run
>
> guix install emacs --with-git-url=… --with-extra-input=autoconf
There's also the 'native-search-paths' field, which cannot simply be
inherited because of the version number embedded within EMACSLOADPATH.
This particular issue could be avoided if the 'native-search-paths'
field were a function of the version number, but that raises migration
issues and I'm not sure it's worth it.
What do you think?
Best regards,
Mark
