GNU bug report logs - #76586
30.1; Question regarding eln-cache

Previous Next

Full log

Message #29 received at 76586 <at> debbugs.gnu.org (full text, mbox):

From: Rahul Martim Juliato <rahuljuliato <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: shipmints <at> gmail.com, 76586 <at> debbugs.gnu.org
Subject: Re: bug#76586: 30.1; Question regarding eln-cache
Date: Wed, 26 Feb 2025 13:30:17 -0300

Right, thanks for the clarification Stephene and Eli!


I'll start migrating my old workflow, having the same 30.1 version on
both machines and give this a try. This feature is indeed VERY useful!
One more killer feature of Emacs 30!


One (a bit crazy) workflow I have will break with this though.


Since compiling .eln is a bit expensive on the cpu side, I used to have
this `by project` docker images which I included Emacs, so I could
quickly ssh into it, rclone my config from network and start working
there with 'pre-compiled' .eln of that architecture in a much less
capable machine (container), and thus, avoiding recompile time.


If I understand it correctly, eln-cache is now  'by machine' and if I'd
like to pre-populate the `eln-cache/emacs-30.1-machinehash` I'd have to
use the `comp-abi-hash` to assembly my new eln-cache path and clone my
.eln into there.


I do this so I can quickly have lsp support while editing inside the
project machine or a clone of it, doing so via tramp (with lsp server on
the remote) is (understandable) slower.


But as I said, it is a bit crazy of a workflow and 99.9999% of the time,
the implemented solution is the best one.


Do I wish a user option to override `comp-abi-hash` would be available
to the lisp user? Yes. Do I think exposing it is a good idea? No. For
that I believe you guys know better :)


Thanks!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.