Home

Welcome to the el-get wiki!

Mailing list

The mailing list archive is at gmane.emacs.el-get.devel. You can subscribe by sending an email to [email protected].

Guidelines for Recipe Authors

An el-get recipe should make code available on the local machine as though it were packaged with Emacs. With very few exceptions, Emacs' own packages:

1. Are loaded only on-demand via autoload
2. Do not make features (such as minor mode and color theme) globally active;
3. Do make features globally available (e.g. via autoloads);
4. Do make features selectively active (e.g., activating a major mode based on filename) when that reflects popular practice.

If a package does not follow these principles "by itself", please try to get the package maintainer to fix that before submitting a recipe that attempts to compensate. If you can't get the package maintainer to make adjustments in a timely fashion, the following compensations in recipes are allowed and encouraged:

1. Major modes can be added to auto-mode-alist for commonly-used, unambigous file patterns.
2. A :pre-init or :post-init may call (autoload ...) "manually"

By default, el-get automatically compiles autoloads for any package written with autoload cookies into a file that's loaded at startup. However, recipes for packages that generate their own autoload files at installation time should disable automatic autoloads and eagerly load that file instead. For example, the nognus recipe contains :autoloads nil and :features gnus-load. Aside from cases like this, there should almost never be a reason to use :features (or, as a last resort, :load).

Portability

Having recipes that work somewhere is definitely a higher priority than making sure that recipes work everywhere. That said, portable recipes are encouraged, and it's often straightforward to make recipes completely portable. Recipes for simple packages will often be portable "automagically," if you just let el-get do what it does naturally: byte-compile the files, put them in the load path, prepare autoloads, make .texi files accessible to the `M-x info' system, etc.

When installation is more complex, it's helpful to use Emacs itself as a portability layer, and especially to avoid using make (often not present on Windows) if possible. In in these cases, a Makefile is often just a thin layer over some invocations of Emacs anyway, which makes it relatively easy to skip make altogether and invoke Emacs directly from your recipe. You can get the full path to Emacs itself by using the variable el-get-emacs in a recipe's :build field. The following recipe shows how you can use el-get-emacs to invoke Emacs twice in a :build step:

(:name apel
       :type cvs
       :module "apel"
       :url ":pserver:[email protected]:/cvs/root"
       :build 
        (mapcar
         (lambda (target)
           (list el-get-emacs
                 (split-string "-batch -q -no-site-file -l APEL-MK -f")
                 target
                 "prefix" "site-lisp" "site-lisp"))
         '("compile-apel" "install-apel"))
        :load-path ("site-lisp/apel" "site-lisp/emu"))