Hi Andrea, Thank you for setting up the Docker image. I had tried to build the native-comp branch on my system but finally was unable to overcome a weird error related to libgccjit (probably because
That's pretty good on (I assume) x86_64, but native-comp branch seems not working on ARM64 Debian Buster at this moment: Not sure if it's a GCCJIT issue or the native-comp branch issue: Any comments
I don't understand. Could you give us more info about what those new byte ops are and what they're used for (and maybe why you think they make things slower in the byte-interpreter, tho I should be
Maybe this was already discussed (in which case please point me to that discussion), but if not: how will this feature be integrated into the Emacs distribution and usage patterns? First, we cannot b
Surely the .eln files won't be in the same directory as the .el and .elc files, at least not on GNU/Linux platforms. On a Debian-style system, .el and .elc will be in /usr/share/emacs/28.1/lisp/foo.e
Yes, that's the option. Implementation wise could just translate into prefixing the output path with this cache directory I think. Andrea -- address@hidden
I would suggest that we make it "opt-in" for at least one major release cycle, to explore the issues among early adopters, before making it the default. -- John Wiegley GPG fingerprint = 4710 CF98 A
Then it should be another dependency for Emacs package (or packaged together with binary?). Though libgccjit is not readily available in some systems. I am using Gentoo and libgccjit is blocked by d
Yeah that happened to me when I was compiling it once on update 7, after my system updated GCC, but libgccjit is not updated automatically, I have to fetch it and compile it manually (Arch Linux).
I think we should reason on the point if moving the .elns into some cache folder would prevent distributing precompiled eln binaries or not. I think is mandatory to retain this capability. Andrea --
You would ultimately need to support at least three locations for these: as distributed, local system level and user level. The user level at least would have the additional complication that it need
Would it make sense to include `emacs-version' in the name, as in: ~/.emacs.d/eln-cache/bar/eln-x86_64-pc-linux-gnu-27.1-d241bf45dde51f21/foo.eln I think that could make it easier to see if the direc
I see you haven't gotten much feedback about this yet, so I'll chime in. This is OK but doubles the length of the effective `load-path`. Another option would be to use ~/.emacs.d/eln-cache/eln-x86_64
This is a good idea. My concerns are on how the user would interact with this cache ex: searching if a given eln exists, what's its date, removing one eln etc. Should the user goes always through an
Hi all, so I did some experimentation on moving the eln into a cache directory. ATM I've something that works this way: Compiling Emacs elns are produced into a dedicate folder in the source tree as
Looks good. Long file names are annoying, so removing that level of directory would make it worse in my book. Good. Fine. We might want to introduce an `eln-load-path` for that. I don't like this id