Doom-emacs: gccemacs support?

[sebastiansturm]

Several people have claimed that gccemacs is stable enough for daily use; after having the first 3 compilation attempts segfault on me, today's the first time I've been able to build it from source and indeed it seems to work very well so far (though right now it's still mostly busy compiling various packages I have installed). What do you think about having doom's cli tool call (native-compile-async) during .elc generation if native-compile-async is defined?

[sebastiansturm]

sorry, this is of course not a bug. Will try to remove this false label if I can

[gagbo]

Can you provide a small patch so people who want to opt in a world full of undefined bugs can try ? :)

[sebastiansturm]

my gccemacs is still (or rather, again) compiling because I decided to recompile .local/straight from scratch. If upfront compilation is not needed (though I'd very much prefer that, also it's much more in line with doom's compilation-centric approach), it is nearly sufficient to add (setq comp-deferred-compilation t) to early-init.el, then start Emacs and be very patient.
That led to Emacs complaining about missing files within the evil-collection directory on next startup though. I thought it might be because the .eln-file resides in a platform-specific subdirectory, so the first thing I'll try once the compilation is done is to symlink non-el files to the eln directory and see if that helps. If it does, I'll write a small function for private use that does this automatically (and maybe post it here), and ask on emacs-devel how to solve this issue properly. If it doesn't help, maybe I'll post the error message here or ask on emacs-devel right away

[sebastiansturm]

so, this time I just did (native-compile-async "~/.emacs.d/.local/straight/build/" t t) and got the same evil-collection error as last time when I restarted Emacs afterwards. That error went away after symlinking ~/.emacs.d/.local/straight/build/evil-collection/modes to the eln-... directory created within; surprisingly no other package raised any complaints so far.
Better take this information with a huge grain of salt though; I still have lots of .eln files from my previous attempt at ~/.emacs.d/.local/straight/repos/.... I guess these are unused but I won't remove them yet as otherwise the remainder of this evening will again be spent recompiling. Will clear out all eln stuff below repos later so I can recompile overnight if this should turn out to break things.
After doom startup, most package-provided functions are described as autoloaded lisp functions by describe-function but after invoking them once, they are described as native code so I guess gccemacs is doing its magic. Haven't done benchmarks of any sort so far

[sebastiansturm]

deleted all .eln files within repos/ now and everything still seems to work

[sebastiansturm]

the path issue is now being discussed as bug #40099 on bug-gnu-emacs (asked by someone else who apparently ran into the same problem with pdftools)

[sebastiansturm]

I'm seeing some evil issues: when pressing v i w at the following point: someiden|tifier, only tifier gets selected. I'll look for a corresponding bug report later or otherwise file one myself. For now, I just removed ~/.emacs.d/.local/straight/build/evil/eln-...; that way evil is only byte-compiled but works correctly while the other packages remain native

[sebastiansturm]

today's build fails on startup with all sorts of autoload-related messages; I assume this is related to https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-04/msg00410.html. Will keep an eye on that bug report and use yesterday's build in the meantime (commit f9a1d4b)

[sebastiansturm]

c5ed3a72 seems to be good again

edit: not so sure after all; I don't get the errors anymore, but invoking describe-function on package-provided commands doesn't show "native function" anymore. Will go back to f9a1d4b again

edit edit: no, I'm a fool. I had used counsel-describe-function instead of plain describe-function. Not sure if counsel-describe-function used to display native functions as such (I'd have thought it just calls describe-function), but at any rate a plain call to describe-function now reproducibly describes supposedly compiled functions as "native compiled Lisp functions" whereas SPC h f does not. disassemble and subr-native-comp-unit seem to work perfectly well, too, so I guess everything is fine with the latest commit

[hlissner]

You'll likely need to request or PR https://github.com/Wilfred/helpful to detect native functions. Doom uses the helpful package instead of the built-in describe-* commands, which counsel is configured to use instead.

[sebastiansturm]

ah, I see. Thanks!