Masao Uebayashi
uebay****@pulte*****
2004年 3月 2日 (火) 11:53:47 JST
ドキュメントです。 $NetBSD$ ========================================================= emacs.mk - a Makefile fragment for Emacs Lisp packages in Pkgsrc ========================================================= Masao Uebayashi <uebay****@NetBS*****> 0 Ideas ======= * Determine the version of GNU Emacs/XEmacs to be used. * Under Pkgsrc, ELPs' Emacs Lisp files are installed... GNU Emacs ${PREFIX}/share/emacs/site-lisp/foo/... XEmacs ${PREFIX}/lib/xemacs/site-packages/lisp/foo/... (Why site-packages? I think I read that 3rd party packages (Pkgsrc is 3rd party for XEmacs!) should be placed there in some documents.) * XEmacs's ELPs' names are prefix'ed by "xemacs-", because an ELP installed for GNU Emacs does nothing for XEmacs, and vice versa. For example, if an ELP "xemacs-foo" depends on another ELP "xemacs-bar", "xemacs-foo" won't work even if "bar" (not "xemacs-bar") is installed. OTOH, "foo" and "xemacs-foo" conflict since they can install any file into the same location. For simplicity and safety in terms of Pkgsrc's package management. XXX Hmm? * Assume each package supports GNU Emacs 21 by default. If the package supports XEmacsen too, define EMACS_VERSIONS_ACCEPTED explicitly before including mk/emacs.mk. 1 Plan ====== To migrate this new framework as gracefully as possible... * Phase 1 Put the new emacs.mk (this file!) as mk/emacs.new.mk. Wrap emacs.mk with USE_NEW_EMACS_MK, which, if defined, turns ELPs include emacs.new.mk. * Phase 2 Disable binary-incompatible interfaces / features in emacs.new.mk. * Phase 3 Adapt all ELPs to emacs.new.mk. During this phase, nothing messy should happen to users. * Phase 4 Enable all new interfaces in emacs.new.mk. After this, ELPs' package names change. Users need to re-install all thier ELP packages. 2 Terminology ============= * GNU Emacs Emacs developed by FSF. * ELP Acronym of "Emacs Lisp (Pkgsrc) Package". mail/vm, editors/jde, and www/emacs-w3m are all ELPs. * Emacs All GNU Emacs and all XEmacs versions. * "Emacs as base" Emacs installed outside Pkgsrc. Linux and Mac OS X have this. * flavor GNU Emacs or XEmacs. (Borrowed from Debian.) * XEmacs Emacs currently developed by the XEmacs project. 3 Variables =========== (The format is in "* NAME (server / client)", where "server" sets the value, "client" reads and uses the value.) * EMACS_BIN (Pkgsrc / ELP) Path to the Emacs executable. Either ${LOCALBASE}/bin/emacs or ${LOCALBASE}/bin/xemacs. * EMACS_COEXIST (ELP / Pkgsrc) A flag set to YES if this ELP can be installed for both GNU Emacs and XEmacs simultaneously (coexist, that is). Defaults to NO. (I don't think ELPs should necessarily coexist, but some of them might be wanted to be so.) For an ELP to coexist, the ELP must install its files into different location by flavor. Usually some modification might be needed since ELPs don't assume they are duplicated in a system. NOTE: Be careful when you set this. Test it much! * EMACS_DEPENDS (ELP / Pkgsrc) A macro to declare a dependency to other ELPs. The syntax is exactly same as the standard DEPENDS macro. EMACS_DEPENDS handles ELPs' package name prefix following the rules shown above. This must not be used for dependency on not-ELP packages. * EMACS_ETCDIR (Pkgsrc / ELP) Directory where miscellaneous files are installed. This directory is an own subdirectory for an ELP. * EMACS_FLAVOR (Pkgsrc / ELP) "emacs" for GNU Emacs, and "xemacs" for XEmacs. Users / ELPs can know the exact Emacs by this value and EMACS_VERSION together. * EMACS_INFODIR (Pkgsrc / ELP) Common directory where ELPS' Info files (*.info) are installed. * EMACS_LISPDIR (Pkgsrc / ELP) Directory where Emacs lisp files (*.el, *.elc) are installed. This directory is an own subdirectory for an ELP; that is, an ELP "foo"'s EMACS_LISPDIR will be .../site-lisp/foo. PKGBASE is automatically appended by emacs.mk. * EMACSPREFIX (Pkgsrc / ELP) Directory where ELP files are installed below. The upstair directory of EMACS_{INFO,LISP,ETC}DIR. Why should this redundant variable be exported despite the existense of EMACS_{INFO,LISP,ETC}DIR? Because not all ELPs have the same configure/build script. Some want this directory as an argument, others not. Most of XEmacs-unware ELPs want only the lisp directory. Some dig subdirectory, others not, etc. For XEmacs-aware ELPs, this variable would be used as an argument for the --with-packagedir configure option. * EMACS_VERSION (Pkgsrc / ELP) The Emacs version number, e.g., "21.3" for GNU Emacs 21.3. Users / ELPs can know the exact Emacs by this value and EMACS_FLAVOR together. * EMACS_VERSIONS_ACCEPTED (ELP / Pkgsrc) Versions which a given ELP can be used for. This defaults to a set of GNU Emacs versions. NOTE: This must be defined before emacs.mk is included. XXX Is it better that each ELP should explicitly specify this? * EMACS_VERSION_DEFAULT (User / Pkgsrc) The Emacs versions Pkgsrc recommends. Defined in bsd.pkg.defaults.mk, may be overridden in /etc/mk.conf. When an ELP is being installed, if you don't have any Emacs installed, install this version assuming that users agree values advertised in bsd.pkg.defaults.mk. * USE_XEMACS (User / Pkgsrc) Do things as XEmacs users want if defined. 4 Issues ======== * Help users' local settings, i.e., fragments for ${HOME}/.emacs. * How to do with Emacsen installed as a part of base? E.g. Mac OS X. * Document how this works briefly. * {Design,document} how to {create,update} {emacsen,ELPs}. * Clarify how -nox11 emacsen are treated. * How to treat "Emacs as base", found on Linux and Mac OS X? * How to treat "Package as base"; Emacs 20 doesn't have elib, Emacs 21 has. * OTOH, some packages are updated and prefered to be installed even if it's in the base. E.g. Gnus. * Test with Pkgviews. * Leim handling. * Can an XEmacs ELP depend on a package in xemacs-packages? * Listing a set of acceptable versions needs massive rewrition of many Makefiles in places when any Emacs version-ups. The notation should be more flexible, for example, xemacs>=214 or like that. * The above is valid for PLIST's ${FOR_xemacs214} too. Actually, some ELPs (e.g. inputmethod/ddskk) configure and change installed files depending on Emacs's flavor, version, features, etc. (Buildlink2 for Emacs Lisp is too much for me to try. ;-) I think it's better to create PLIST dynamically for these ELPs than examining their configuration processes and manually gather those confitions into PLISTs with ${FOR_xemacs214} etc. * What happens if an XEmacs is updated??? 5 Credits ========= The design is heavily affected by Python packages written by Matthias Drochner.
