Emacs infrastructure: Overhaul
Needs ReviewPublic
Actions

Authored by jrm on Fri, Mar 20, 8:45 PM.

Details

Reviewers

Summary

For a USES=emacs port such as print/pdf-tools, if we want to install
byte-compiled elisp, we must have both build and run dependencies on
some flavor from editors/emacs or editors/emacs-devel. However, we
cannot easily create a flexible dependency so that any flavor of either
Emacs port could satisfy the dependency. The pdf-tools package must
depend on a specific Emacs package, so we need flavors/packages for
pdf-tools, pdf-tools-emacs_canna, pdf-tools-emacs_nox,
pdf-tools-emacs_wayland, and so on. With over 100 USES=emacs ports,
adding a new Emacs flavor means creating over 100 new packages. It
quickly becomes unmanageable, especially when considering
editors/emacs-devel and its flavors.

To work around this problem, we will no longer install any byte-compiled
elisp with any elisp port. This means we no longer need build or run
dependencies. Instead, we will hook into Emacs's native compilation
machinery to have that elisp natively compiled in the standard cache
under the user's home directory.

Diff Detail

Repository

R11 FreeBSD ports repository

Lint

Lint Skipped

Unit

Tests Skipped

Build Status

Buildable 71609
Build 68492: arc lint + arc unit

Event Timeline

jrm requested review of this revision.Fri, Mar 20, 8:45 PM

jrm created this revision.

Harbormaster completed remote builds in B71598: Diff 174040.Fri, Mar 20, 8:45 PM

This is still in the design stage, so I haven't:

made the changes needed for editors/emacs
made the changes needed to most USES=emacs ports

I'm testing it with my installation of editors/emacs-devel, and so far so good. I considered doing something similar for byte-compiled elisp, but I don't think that will work because the documentation for byte-compile-dest-file-function says

Note that the assumption that the source and compiled files are found in the same directory is hard-coded in various places in Emacs.

If we really wanted byte-compiled files, we would have to do something at package installation time as root, so the .elc files can be installed alongside the .el files. I'm leaning against that approach because it requires running things as root on the target system and would scatter untracked files under ${LOCALBASE}. Given those concerns, native compilation is the right path for users who care about performance.

Thoughts?

Incorporate necessary changes to editors/emacs

Harbormaster completed remote builds in B71609: Diff 174061.Sat, Mar 21, 2:20 AM