Xemacs 21.4, packages from CVS -- Installing a small set of packages without loose ends?

Xemacs 21.4, packages from CVS -- Installing a small set of packages without loose ends?

Post by dpesche » Mon, 04 Feb 2008 07:43:06


I'm running Xemacs 21.4.20 on Mac OS 10.3.7 -- I installed Xemacs
through
the MacPorts utility. The MacPorts port doesn't come with any
packages
installed, so I had to get them from CVS and install them. It wasn't
hard,
but it isn't very tidy either. For example, I am still getting this
warning,
which I gather from a Web search is not a new problem:

(1) (warning/warning) Autoload error in: /opt/local/lib/xemacs/xemacs-
packages/lisp/ede/auto-autoloads:
Symbol's function definition is void: eieio-defclass

And I've seen warnings about other undefined symbols, each of which
needs
to be investigated (by me or someone else).

The Xemacs Web site already mentions that the package-installation
menu
commands require a few packages to be installed. Frankly that's
broken,
but at least I've been warned. I would say there are two other big
problems:

1. Many other supposedly built-in features of Xemacs, like the
de ***
and the report-xemacs-bug command, also require packages. These
features are mentioned in the info manual and on the Web site but
their reliance on packages isn't, as far as I can tell.

2. I have not found if it's possible to detect which packages are
really
essential and install just those. Checking out the CVS sources and
doing "make" in the top level calculates dependencies for all the
packages, so that by the time I do "make" in an individual
package's
directory, it's too late.

This wouldn't fix the underlying problems, but it would make common
uses of Xemacs work, which might then allow the problems to be
investigated more productively. Or it would make things like the
MacPorts port easier to maintain.

I've formed the hypothesis that dependency calculations are the major
cause of all this brokenness -- the evaluator knows about the de ***
but
it's in a package; commands like report-xemacs-bug require things in
packages,
which then require more packages; and something is clearly broken
inside
packages like ede and eieio. Is this hypothesis accurate? Is there
really
any hope of fixing it by statically analyzing the contents of each
package?

Thanks,

-- Derek