With native comp support in the pipeline for emacs, there is a need to be able to run batch-native-compile in addition to/instead of running batch-byte-compile when calling elisp-compile if emacs was built with native compile support enabled. I think the things that need to be implemented in the eclass are to check whether emacs was built with native compiler support enabled and if it was to call batch-native-compile instead of calling batch-byte-compile. In principle batch-native-compile should also create the .elc files, but I can't test that to be 100% sure right now due to a bug in the development branch of emacs. This is mostly a prospective bug since it still takes quite some doing to get emacs compiling with native comp and sys-devel/gcc[jit] still has some outstanding issues https://bugs.gentoo.org/569608 and https://bugs.gentoo.org/583010. For the record I build from https://github.com/tgbugs/tgbugs-overlay/blob/master/app-editors/emacs/emacs-28.0.9999-r1.ebuild with the following package environment settings. #+begin_src bash :tangle /su:localhost:/etc/portage/env/emacs-native-comp :tangle no EGIT_OVERRIDE_REPO_EMACS="https://github.com/emacs-mirror/emacs.git" EGIT_OVERRIDE_BRANCH_EMACS="feature/native-comp" #+end_src #+begin_src bash :tangle /su:localhost:/etc/portage/package.env/app-editors :tangle no =app-editors/emacs-28.0.9999-r1 emacs-native-comp #+end_src Reproducible: Always
Update on the approach. batch-native-compile does not produce elc files, so rather than replacing the call to batch-byte-compile is should just be called afterward if native comp is enabled.
Ping. This will land in emacs master soon.
Yes, I am well aware. No action until then.
feature/native-compile was merged to master in commit 289000e.
(In reply to Ulrich Müller from comment #3) > Yes, I am well aware. No action until then. I shouldn’t have doubted you :)
ping
(In reply to Sam James from comment #6) > ping I tend to close this as wontfix. IIUC every rebuild of Emacs would invalidate the installed *.eln files.
I think the fact that *.eln files need to be rebuilt along with emacs would be an indication that we would want the eclass to do this so that all system package eln files wouldn't be built per user but shared by the system. I realize this would require a rebuild of all system installed elisp packages when building a new emacs release, but I think that is actually what we want? As a note, the many changes in the bytecode have also made the bytecode backward incompatible requiring a rebuild if a user accidentally builds the elc files with the newest version of emacs on their system.
(In reply to Tom Gillespie from comment #8) > I think the fact that *.eln files need to be rebuilt along with emacs would > be an indication that we would want the eclass to do this so that all system > package eln files wouldn't be built per user but shared by the system. > > I realize this would require a rebuild of all system installed elisp > packages when building a new emacs release, but I think that is actually > what we want? The problem is that it introduces a dependency on a specific build of Emacs, and there's no package manager support for this. It becomes even worse for binary packages.
The compiler ABI hash (comp-abi-hash, also last part of comp-native-version-dir) is computed from the following values: - ABI_VERSION (currently "5") - emacs-version - system-configuration (i.e. the GNU triplet) - system-configuration-options (contains all arguments passed to configure, plus the environment variables CFLAGS, CPPFLAGS and LDFLAGS; see emacs_config_options in configure.ac) - comp-subr-list (i.e. the list of all internal functions) So, at least a simple reinstallation of Emacs will _not_ change the hash. It will change however if a USE flag is changed (because that will affect configure options), if CFLAGS etc. are changed, and for every revision bump. (In reply to Ulrich Müller from comment #9) > The problem is that it introduces a dependency on a specific build of Emacs, > and there's no package manager support for this. It becomes even worse for > binary packages. From discussion in #gentoo-lisp: What we could do is to install the *.eln files not as part of the package's installation image, but write them to a system-wide cache under /var/cache. This could be done e.g. in pkg_preinst() or pkg_postinst(). Cleanup of stale cache entries could then be done in pkg_postrm() of the package, and also in pkg_postrm() of app-editors/emacs. We could also consider adding some of the functionality to emacs-updater or some other tool.
