Re: new emacs framework

[蟹澤翔太 <zakinko%snowrabbit.org@localhost>]

Hi Thomas,

Sorry for the slow reply.  I have just moved to a new job, and it took
me a while to get back to this.

Thank you for committing the framework.  I have moved my branch onto
modules.mk 1.43 from current trunk; almost everything I had is now in
the tree, and what remains is the coexistence part below.

The emacs20, emacs29, emacs30 and emacs31 packages need not conflict
with each other.  With a few lines in each Makefile and an
ALTERNATIVES file for bin/emacs, all four install together on my test
box, each starting and loading its own site-lisp; the X and nox builds
of one version still conflict, as they do now.  Moving to a new Emacs
could then be done with the old one still there, an update that
breaks something leaves the previous version to switch back to, and a
package that misbehaves can be tried on another Emacs to see whether
it is one version only.  Doing this turned up a few packages, apel
among them, that find their Emacs as "emacs" on PATH rather than the
one being built for; small diffs for those are in the same place.

  https://github.com/zakinko/pkgsrc-zakinko/tree/emacs-coexist-versions/emacs-framework

One thing in 1.43 that I think is a bug.  The comment says one binary
package serves both builds of an Emacs, and _EMACS_REQD_OTHER is
computed for that, but it is never used, so a package only depends on
the build it was made for.  On a box with only emacs30-nox11, building
something with EMACS_TYPE=emacs30nox that needs apel, flim or semi
goes wrong: the dependency is built from the pattern emacs30-apel,
which reads as emacs30, so it asks for the X build and starts on
editors/emacs30.  These two lines fix it on a clean trunk tree:

  _EMACS_REQD:=	{${_EMACS_REQD:C/[<>=].*//},${_EMACS_REQD_OTHER}}${_EMACS_REQD:C/^[^<>=]*//}

placed just before "DEPENDS+= ${_EMACS_REQD}:${_EMACS_PKGDIR}", and

  BUILDLINK_ABI_DEPENDS.emacs?=	${_EMACS_REQD}

just inside ".if defined(EMACS_BUILDLINK)", since
editors/emacs30/buildlink3.mk otherwise narrows it back to
emacs30>=30.1.  With them, apel, flim and semi build as dependencies on
the nox-only box, and each records {emacs30,emacs30-nox11}>=30.1<31,
which matches either build of 30 and no other version.

One small thing in 1.43: the comment at the top and
_EMACS_PKGNAME_PREFIX.xemacs say "xemacs-", while the line that takes
effect gives xemacs214- and xemacs215-.  I think "xemacs-" is the
better of the two: 21.4 and 21.5 both install into
lib/xemacs/site-packages/lisp, so xemacs214-foo and xemacs215-foo
would be the same files under two names.

One more thing: elisp-compat, one file that defines what an older
Emacs lacks and newer elisp reaches for (subr-x string functions,
setq-local, with-eval-after-load, prog-mode, syntax-ppss, alist-get
and so on, plus a regexp translator for Emacs 20).  From 22.3 on it
only adds what is missing and leaves everything else alone; on 20.7
and 21.4 it also wraps split-string and a couple of others to accept
the newer arguments.  I checked it on each Emacs from 20.7 to 31.1.

  https://github.com/zakinko/elisp-compat

These are suggestions that go with this change; I would be glad if you
could consider them.

Thanks,
Showta

> 2026/09/25 18:58、Thomas Klausner <wiz%NetBSD.org@localhost>のメール:
> 
> Hi!
> 
> TL;DR: new emacs framework in tree, some PKGNAMEs changed, some
> packages will be removed
> 
> With a lot of help from Showta Ishizaki (thank you very much!) I've
> just committed improvements to the emacs module framework
> (editors/emacs/modules.mk).
> 
> It now supports the features we expect from a module framework:
> 
> - allow specifying supported versions
> 
> - allow specifying unsupported versions
> 
> - reduce conflicts between versions (this is not as important as
>  e.g. for Python, because the base emacs* and xemacs* packages still
>  conflict with each other)
> 
> - tag the PKGNAME with the version it was built for; so e.g. "magit"
>  is now called "emacs30-magit" etc. depending on the version it was
>  built for
> 
> - build all supported versions of a module in bulk builds
> 
> Different to the other frameworks:
> 
> - we have emacs* and emacs*nox, the reduced version without X support;
>  since they use the same byte compiler and provide the same
>  functions, there is only one emacs30-foo package that supports both
>  emacs30 and emacs30-nox11 by default. This also means you only need
>  to specify "emacs30" in EMACS_VERSIONS_ACCEPTED; if a package really
>  only supports one of the two "flavors", you can forbid the other
>  version in EMACS_VERSIONS_INCOMPATIBLE - we don't have any such
>  packages in the tree right now.
> 
> I've done repeated bulk builds and marked all packages with the
> (x)emacs versions that they were packaging successfully for. I have
> _not_ tested all of them, and it might be possible to fix some of
> them.
> 
> This currently leaves the following packages without _any_ (x)emacs
> version that builds them:
> 
> chat/emacs-jabber
> devel/ecb
> devel/semantic
> mail/vm
> misc/elscreen
> misc/lookup
> wip/cedet
> wip/elscreen-current
> wip/slime
> wip/undo-tree
> 
> I plan on removing these packages from the tree in a week, unless
> someone speaks up for them. (In the meantime, they will just fail to
> build and should not cause bulk build scan failures - at least they
> don't for me.)
> 
> Enjoy!
> Thomas