This changes the buildlink3.mk files to use an include guard for the
recursive include. The use of BUILDLINK_DEPTH, BUILDLINK_DEPENDS,
BUILDLINK_PACKAGES and BUILDLINK_ORDER is handled by a single new
variable BUILDLINK_TREE. Each buildlink3.mk file adds a pair of
enter/exit marker, which can be used to reconstruct the tree and
to determine first level includes. Avoiding := for large variables
(BUILDLINK_ORDER) speeds up parse time as += has linear complexity.
The include guard reduces system time by avoiding reading files over and
over again. For complex packages this reduces both %user and %sys time to
half of the former time.
Don't call pkg_info to get the installed Emacs version; always use the
version matching EMACS_TYPE set by users. Be DEPENDS to it. This should
address pkg/37146 by Aleksey Cheusov.
While here convert some emacs lisp packages to user-destdir.
1) Simplify the way how an emacs version is picked when no emacs
is installed, but a user try to install an Emacs Lisp package.
Just pick up the version set as EMACS_TYPE than searching for
versions already installed etc. If the EMACS_TYPE version is
not supported by the Emacs Lisp Package, just fail. EMACS_TYPE
be default to GNU Emacs 21.
(In other words, users should set EMACS_TYPE as they want.
Otherwise GNU Emacs 21 is used.)
2) All Emacs Lisp Packages *must* prepend EMACS_PKGNAME_PREFIX to
a) the PKGNAME itself, and b) PKGNAME in its dependency lines.
EMACS_PKGNAME_PREFIX is expanded to "xemacs-" when XEmacs is
used. This keeps dependency graph of Emacs-Lisp-packages-
installed-for-XEmacs consistent.
3) Document EMACS_* variables as much as possible.
4) Provide more cookies for PLIST. Maybe utilized later.
Note that the 2) change doesn't affect the default, GNU Emacs 21
behaviour. So no version / revision bumps in this commit.
* Don't depend on xemacs-packages.
While files of xemacs-packages are installed into
${PREFIX}/lib/xemacs/xemacs-packages,
individual Emacs lisp packages use
${PREFIX}/lib/xemacs/site-packages,
so these are never overwritten.
Let's think that these two parts are separate. Individual Emacs lisp
packages depend on another individual ones, never need to depend on
xemacs-packages. This should make things simpler.
xemacs-packages actually includes the old version of apel;
this package overrides it, which could be confusing.
Possibly we should remove apel from xemacs-packages?
(some packages require new apel)
Many small changes which enhance APEL's functionality. Due to the
charasteristic of APEL as a portability layer of emacsen, no user visible
change, but more portability, possibly.
