[Bug: 21.4.18] site-lisp not in load-path
Stephen J. Turnbull
stephen at xemacs.org
Wed Jan 18 02:37:53 EST 2006
>>>>> "vin" == Vin Shelton <acs at xemacs.org> writes:
vin> FWIW, I think it's unlikely that the (stable) 21.4 branch
vin> will ever support the new feature 'site-packages/*/lisp', but
vin> sometimes patches convince me to change my mind.
Mike has claimed that this is basically already supported in XEmacs,
at least in 21.5 but ISTR in 21.4 too; what's missing is an audit of
the build infrastructure, and maybe a few tweaks to the package-
finding code. In fact, the following proposal can probably be
implemented as a normal XEmacs package with a bit of abuse of its
For packages built entirely by third parties, the following transition
strategy is easy to implement and essentially riskless but was vetoed
at the brainstorm stage by Mike (and I think Ben) several years ago
(and ignored by everybody else).
(1) Create a new hierarchy "opaque-packages" sibling to
xemacs-packages, mule-packages, and site-packages.
(2) Add code to the package-autoloading code to look in each
subdirectory of opaque-packages for the library
These packages are called "opaque" because auto-autoloads is entirely
responsible for configuring the package, including setting up
load-path, exec-path, and any other LISP environment the package
needs. XEmacs knows nothing about the internal structure of such
packages; it doesn't even know for sure that .../ess/lisp contains any
LISP other than auto-autoloads. It's not called "3rd-party" because I
think XEmacs packages should work this way too!
Of course we _should_ provide further infrastructure support down the
1. other automatic package configuration like custom-load and _pkg.el
2. a utility to insert the package's main LISP directory in
load-path (the arg is a path relative to the package's root,
3. similar utilities for data, info, executables
and probably other stuff. But we don't need to do it immediately. In
fact, we shouldn't do anything for opaque-packages automatically, not
before thinking about issues of standalone executables (think
oo-browser) and ELLs, both of which should be installable as packages
(although because they're platform-dependent, I don't think XEmacs.org
should distribute them, except perhaps for MS Windows).
Since as it stands we're asking such packages to do random things to
the LISP environment, a warning should be logged (always) and
displayed (by default) when an opaque package is auto-loaded. There
should be a customizable list of expected opaque packages (ie, their
main feature-symbols) and warning display would be suppressed for
Note that complex packages like JDEE and Emacspeak already have
internal mechanisms for finding their data, executables, and help;
they would basically just drop in to this scheme with a couple of
autoload cookies that they probably already have.
NB: At this point, this has nothing to do with XEmacs builds of such
packages and nothing to do with pui. It would make David Kastrup's
proposal to distribute AUCTeX from the AUCTeX project a bit simpler,
but it doesn't address his complaints about the XEmacs distribution of
AUCTeX at all.
Of course in the near term I'd like to support a lot of the "usual
setup" automatically, and also support such packages in pui (pretty
trivial, I would think, since pui just untars to install, and does
"cat pkginfo/$package.MANIFEST | xargs rm" to uninstall).
Supporting builds of such packages would be a longer term project, but
presumably not terribly hard for 3rd party packages since upstream
would have already done most of the work. I think it's a good bet
that Steve Youngs would like this too (he's the guy who implemented
the symlink trees for run-in-place for the packages, which is needed
primarily because the package and functional layers in source packages
are reversed in installed packages).
We'd also probably want to install info and maybe certain kinds of
data (toolbar icons, for example) to a few shared directories rather
than to dozens of $package/info directories, I guess. But that's an
optimization; it can wait, I think.
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
More information about the XEmacs-Beta